Closed Bug 1388356 Opened 5 years ago Closed 5 years ago

helper_touch_action.html ends up showing task view in windows 10

Categories

(Core :: Panning and Zooming, defect, P3)

57 Branch
All
Windows
defect

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox57 --- fixed

People

(Reporter: jmaher, Assigned: jmaher)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(1 file)

I have been looking at the remaining failures to get our unittests running on windows 10.  While there are a lot of variables, I have found that locally on windows 10 I can reproduce many of the issues.

In this case I am running gfx/layers/apz/test/mochitest/test_group_touchevents.html, which ends up failing with a timeout.  The reason why is we get into the task view on windows 10:
https://public-artifacts.taskcluster.net/BSmHTEwSRJewW-Hk8VmtPQ/0/public/test_info/mozilla-test-fail-screenshot_rubsid.png

I see this locally.  Narrowing this down, I see this on some of the diagonal touch drags we do and changing the values slightly avoids this task view.  here is a diagonal call we have:
https://dxr.mozilla.org/mozilla-central/source/gfx/layers/apz/test/mochitest/helper_touch_action.html#49

Given this line:
  yield ok(synthesizeNativeTouchDrag(target, 10, 10, (40 + TOUCH_SLOP), (40 + TOUCH_SLOP)),
     "Synthesized diagonal drag (1), waiting for touch-end event...");

if we change the 10,10 to 50,50 it works.


I really don't like that solution, but it does get us somewhere.



the second issue with this test is in test_helper_action_regions.html:
https://dxr.mozilla.org/mozilla-central/source/gfx/layers/apz/test/mochitest/helper_touch_action_regions.html#194

I get errors like this:
112 INFO TEST-PASS | gfx/layers/apz/test/mochitest/test_group_touchevents.html | helper_touch_action_regions.html | Chrome touch counter registered
113 INFO TEST-PASS | gfx/layers/apz/test/mochitest/test_group_touchevents.html | helper_touch_action_regions.html | Finished setting up event queue
114 INFO TEST-PASS | gfx/layers/apz/test/mochitest/test_group_touchevents.html | helper_touch_action_regions.html | Got baseline snapshot
115 INFO TEST-PASS | gfx/layers/apz/test/mochitest/test_group_touchevents.html | helper_touch_action_regions.html | Touchstart processed in chrome process
GECKO(17232) | InjectTouchInput failure. GetLastError=1460
116 INFO TEST-UNEXPECTED-FAIL | gfx/layers/apz/test/mochitest/test_group_touchevents.html | helper_touch_action_regions.html | Touchmove processed in chrome process
    spawnTest/w.ok@gfx/layers/apz/test/mochitest/apz_test_utils.js:231:52
    test@gfx/layers/apz/test/mochitest/helper_touch_action_regions.html:195:5
    driveTest@gfx/layers/apz/test/mochitest/apz_test_utils.js:305:19
GECKO(17232) | InjectTouchInput failure. GetLastError=87


commenting out the lines 192->214 in the source file yields success- so there is a problem there.
:kats, could you help me figure out a realistic solution to get this running on windows 10?
Flags: needinfo?(bugmail)
(In reply to Joel Maher ( :jmaher) (UTC-9) from comment #0)
> Given this line:
>   yield ok(synthesizeNativeTouchDrag(target, 10, 10, (40 + TOUCH_SLOP), (40
> + TOUCH_SLOP)),
>      "Synthesized diagonal drag (1), waiting for touch-end event...");
> 
> if we change the 10,10 to 50,50 it works.

This seems like a fine solution for this particular line. I guess starting the swipe at 10,10 triggers the windows "show task view" gesture. For the test it doesn't matter what the actual coordinates of the drag are, as long as it's a diagonal drag of 40px (even that can be adjusted if needed). If we add a comment about this, I have no problem with this change.

> the second issue with this test is in test_helper_action_regions.html:
> https://dxr.mozilla.org/mozilla-central/source/gfx/layers/apz/test/mochitest/
> helper_touch_action_regions.html#194
...
> GECKO(17232) | InjectTouchInput failure. GetLastError=1460
...
> GECKO(17232) | InjectTouchInput failure. GetLastError=87

I ran into this problem before, in bug 1313170. (The 1460 code is ERROR_TIMEOUT). See https://hg.mozilla.org/integration/autoland/rev/9b244c814861 for the fix I went with, we can do the same thing here. Just update test_group_touchevents.html to run the helper_touch_action_regions subtest with "apz.test.fails_with_native_injection" set to isWindows. If that doesn't take care of it we can investigate more.
Flags: needinfo?(bugmail)
and on try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=2d3c798d125b38705fc491606ffe1e1ada67eafe
Assignee: nobody → jmaher
Status: NEW → ASSIGNED
Attachment #8895021 - Flags: review?(bugmail)
Comment on attachment 8895021 [details] [diff] [review]
add pref for windows

Review of attachment 8895021 [details] [diff] [review]:
-----------------------------------------------------------------

Please update the commit message to describe what the patch is doing rather than restating the bug title.
Attachment #8895021 - Flags: review?(bugmail) → review+
Pushed by jmaher@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5218fdb57fa7
add pref apz.test.fails_with_native_injection for windows to allow touch based events to work in windows 10 tests. r=kats
Duplicate of this bug: 1382988
OS: Unspecified → Windows
Priority: -- → P3
Hardware: Unspecified → All
Whiteboard: [gfx-noted]
Version: unspecified → 57 Branch
https://hg.mozilla.org/mozilla-central/rev/5218fdb57fa7
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in before you can comment on or make changes to this bug.