Closed Bug 1313170 Opened 8 years ago Closed 8 years ago

helper_long_tap.html | Got a mouselongtap - got "touchend", expected "mouselongtap" when GPU process enabled

Categories

(Core :: Graphics, defect, P3)

Unspecified
Windows 8
defect

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: rhunt, Assigned: kats)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(2 files)

      No description provided.
OS: Unspecified → Windows 8
Priority: -- → P3
Whiteboard: [gfx-noted]
Version: unspecified → Trunk
Also, this is the failure in question: https://treeherder.mozilla.org/#/jobs?repo=try&author=danderson@mozilla.com&selectedJob=29898382

Seems to be win8 only, and win8 jobs are hidden on central branches, so this technically doesn't need to block gpu process enabling. It might be a legit bug though.
From the log it looks like during the previous test (helper_bug1162771.html) touch injection fails for some reason. The log has this:
 INFO -  InjectTouchInput failure. GetLastError=87
87 appears to be the ERROR_INVALID_PARAMETER documented at [1]. I'm not sure what's going on there since the touch events seem to get through and that particular subtest passes.

Later after the helper_long_tap has occurred, there's another failure in the log:
 INFO -  InjectTouchInput failure. GetLastError=1460
Where 1460 is ERROR_TIMEOUT. Not sure what that's about either.

I think I'll try to repro this locally tomorrow, it might be easier to debug.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/hh802881(v=vs.85).aspx
Parking with me for now.
Assignee: nobody → bugmail
I can reproduce this locally on my Win8 device even without the GPU process patches. The ERROR_INVALID_PARAMETER is because helper_bug1162771.html does a thing where it makes the element display:none, which results in different coordinates being used for the touchend than were for the touchstart. The windows injection code doesn't like this, presumably because it expects to get touchmove events in between.

The ERROR_TIMEOUT is the more serious problem though, because according to the docs [1] the injection mechanism requires a new input frame at least every 100ms. In our tests we sometimes wait longer than 100ms because we're waiting for a repaint or (in this case) a long-tap timeout, so we can't really satisfy that requirement.

I think maybe the best option here is to not use the Windows touch injection code and fall back to the fallback code we have that runs for platforms that don't support touch injection. I'll do a try push with that and see if it works.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/hh802881(v=vs.85).aspx
^ That's green. I'll add a new pref to force us into the fallback touch injection path and make sure it's set on the relevant tests.
Comment on attachment 8805945 [details]
Bug 1313170 - Use the widget-level touch injection instead of the OS-level touch injection for some tests.

https://reviewboard.mozilla.org/r/89544/#review89020
Attachment #8805945 - Flags: review?(dvander) → review+
Comment on attachment 8805946 [details]
Bug 1313170 - Ensure that the touchend events in helper_bug1162771 are sent with the correct coordinates.

https://reviewboard.mozilla.org/r/89546/#review89022
Attachment #8805946 - Flags: review?(dvander) → review+
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9b244c814861
Use the widget-level touch injection instead of the OS-level touch injection for some tests. r=dvander
https://hg.mozilla.org/integration/autoland/rev/c051b525c297
Ensure that the touchend events in helper_bug1162771 are sent with the correct coordinates. r=dvander
https://hg.mozilla.org/mozilla-central/rev/9b244c814861
https://hg.mozilla.org/mozilla-central/rev/c051b525c297
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: