GNOME Shell reports invalid coordinates to dogtail in Tails/Stretch
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.
Enable the bugfix-11718-fix-dogtail-vs-gnome-shell APT overlay.
main|amd64: gir1.2-mutter-3.0 3.22.4-1+tail1
main|amd64: libmutter-dev 3.22.4-1+tail1
main|amd64: libmutter0i 3.22.4-1+tail1
main|amd64: libmutter0i-dbgsym 3.22.4-1+tail1
main|amd64: mutter 3.22.4-1+tail1
main|amd64: mutter-common 3.22.4-1+tail1
main|amd64: mutter-dbgsym 3.22.4-1+tail1
main|i386: mutter-common 3.22.4-1+tail1
main|source: mutter 3.22.4-1+tail1
Test suite: rename step.
The current name is completely wrong -- the menu navigation was
completely broken due to #11718 and it was thought we would be able to
fix it and revert the GNOME Activities workaround, and just skip the
renaming since the workaround was temporary. Well, it seems that the
menu handling still is not reliable, even with #11718 fixed, so let's
stick with what has worked pretty good during the feature/stretch
#1 Updated by anonym over 3 years ago
- Type of work changed from Research to Wait
I worked around this with 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 over 3 years ago
- Status changed from Confirmed to Resolved
- Assignee deleted (
- 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.
#5 Updated by anonym almost 3 years ago
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.
#7 Updated by anonym almost 3 years ago
- 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
#8 Updated by intrigeri almost 3 years ago
- 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 almost 3 years ago
- 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 :)
#12 Updated by anonym almost 3 years ago
I think I want to conclude this ticket with 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 #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)