Bug #11718

GNOME Shell reports invalid coordinates to dogtail in Tails/Stretch

Added by anonym 2016-08-25 07:12:49 . Updated 2017-06-12 16:07:41 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
Tails_3.0
Start date:
2016-08-25
Due date:
% Done:

100%

Feature Branch:
bugfix/11718-fix-dogtail-vs-gnome-shell
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

When trying to click on e.g. the Applications menu button on the top bar, Dogtail says:

ValueError: Attempting to generate a mouse event at negative coordinates: (-1258053527.5,13.5)

This is not the case on a default Debian Stretch/Sid install, so it could be that Tails GNOME configuration causes this some how, or that the APT snapshot we made for feature/stretch (2016081703) has a package causing this breakage.

Files

mutter.patch (4870 B) anonym, 2017-05-12 13:23:22

Subtasks

History

#1 Updated by anonym 2016-08-25 08:04:38

  • Type of work changed from Research to Wait

I worked around this with commit:413a61c0fb0ef5a241c575fc0f02f32b0250baf5 and will be blocked from trying to do more gnome-shell stuff with Dogtail until this is fixed. For now we’ll wait to the next time we update the APT snapshot, hoping it will magically be fixed then.

#2 Updated by anonym 2016-11-16 13:11:26

  • Status changed from Confirmed to Resolved
  • Assignee deleted (anonym)
  • Type of work changed from Wait to Code

This issue has been magically fixed in Debian after switching to the 2016111502 ‘debian’ APT snapshot. So I’ve reverted commit:a6c7c29fc705a79122951b1803a301de9656c00c.

#3 Updated by anonym 2017-01-30 10:59:48

  • Status changed from Resolved to Confirmed
  • Assignee set to anonym

This ticket was supposed to be re-opened, because the bug is still there. The old workaround was reintroduced with commit:f4914124d5ba9340137d54c70b5d2344fb49f251.

#4 Updated by intrigeri 2017-03-19 09:35:55

  • Subject changed from gnome-shell reports invalid coordinates to dogtail in Tails/Stretch to GNOME Shell reports invalid coordinates to dogtail in Tails/Stretch

#5 Updated by anonym 2017-05-12 13:08:40

intrigeri gave me a tip which lead to:

I applied the two patches from the GNOME bug to mutter 3.22.4-1, built packages, booted Tails/Stretch to the Greeter (with passwd= set on the kernel cmdline), switched to a VT, mounted a filesystem containing the packages, installed them, restarted the Greeter and logged in. My first attempt to make Dogtail find and click GNOME Shell’s Places menu worked! But all subsequent attempts shifted the X-coordinate too much to the right for some reason, so it’s still useless for us.

In fact, I later rebooted to retry without the patched packages, and I have the exact same result (consistently, cause I rebooted three times and got the same coordinates). So for some reason we get valid coordinates even without the patch (which wasn’t the case when this ticket was opened), but they are still incorrect (right shifted) so Dogtail is useless when interacting with GNOME Shell.

#6 Updated by anonym 2017-05-12 13:24:01

(Attaching the full packaging patch in case I want to look at it again).

#7 Updated by anonym 2017-05-12 17:52:19

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 30
  • Type of work changed from Code to Wait

Woah, never mind! I suspected that I made a mistake while testing above, and I indeed had (too boring to mention here), because when I retried (this time building an ISO with the patched mutter packages) it worked perfectly! Phew! It made no sense to me that it didn’t work, so this brings me some peace of mind. :)

I’ve asked to get these patches applied to Stretch’s mutter: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862441

#8 Updated by intrigeri 2017-05-20 07:22:01

  • Type of work changed from Wait to Communicate

The timing is very short so either we are fast on the Debian bug (providing requested info, maybe attaching a debdiff and offering to NMU + submit an unblock request) or we give up and build our own patched mutter (until we upgrade to the version that has the fix).

#9 Updated by intrigeri 2017-05-27 08:37:58

  • Type of work changed from Communicate to Code

It’s become too late for fixing this in Stretch given the impact is unclear outside of our test suite.

So let’s now focus on assessing whether if it’s worth shipping a patched mutter in 3.0, or if we can postpone. This problem seems to impact two things in our test suite potentially:

  • /^I start "([^"]+)" via the GNOME "([^"]+)" applications menu$/: I think I’ve seen failures in screen.wait('GnomeActivitiesOverview.png', 10), that might be caused by our workaround, so perhaps that’s worth fixing in 3.0?
  • /^all notifications have disappeared$/: I don’t seem to recall any practical issue with our current workaround; do you?

Anyway, it seems to me that building+uploading a patched mutter is harmless and might actually be cheaper than evaluating whether it’s really worth it, so I would say: just do it :)

#10 Updated by anonym 2017-06-02 21:47:49

  • % Done changed from 30 to 50
  • QA Check set to Ready for QA
  • Feature Branch set to bugfix/11718-fix-dogtail-vs-gnome-shell

Let’s see what Jenkins thinks!

#11 Updated by anonym 2017-06-06 16:39:48

anonym wrote:
> Let’s see what Jenkins thinks!

Jenkins hated it! 50+ failures! But build 9 should be good! :)

#12 Updated by anonym 2017-06-07 14:51:12

I think I want to conclude this ticket with commit:be98070a42688129b41e3931d15f315c35db7f4a — I initially had pushed code here which reverted back to using the GNOME Applications menu, but it turns out it’s much more fragile than the workaround based on GNOME Activities Overview we have gotten used to when working on feature/stretch. So I’ve force-pushed the current branch, putting those experimentes into Feature #12652 that I intend to work on post-3.0.

OTOH, this ticket can easily be postponed until after 3.0 as well.

Now I’m just gonna make sure my step renaming didn’t upset Jenkins… (should be build #12

#13 Updated by anonym 2017-06-08 13:38:22

  • Assignee changed from anonym to intrigeri

anonym wrote:
> Now I’m just gonna make sure my step renaming didn’t upset Jenkins… (should be build #12

Success! Please review’n’merge!

#14 Updated by intrigeri 2017-06-08 14:56:31

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

Applied in changeset commit:c42fbe19a9c08fad07a24d20edef8ecb11760fcb.

#15 Updated by intrigeri 2017-06-08 14:56:54

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#16 Updated by intrigeri 2017-06-12 16:07:41

  • Status changed from Fix committed to Resolved