Closed Bug 1368603 Opened 7 years ago Closed 6 years ago

Intermittent gfx/layers/apz/test/mochitest/test_group_mouseevents.html | Test timed out.

Categories

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

55 Branch
x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: kats)

References

Details

(Keywords: intermittent-failure, Whiteboard: [gfx-noted][stockwell fixed:backout])

Attachments

(1 file)

OS: Unspecified → Linux
Priority: -- → P3
Hardware: Unspecified → x86_64
Whiteboard: [gfx-noted]
Version: unspecified → 55 Branch
Retriggers on inbound are pointing at bug 1368286 as the culprit. This is also looking frequent enough that it probably warrants more attention than P3 would suggest it'll get.
thanks for narrowing this down :ryanvm
Whiteboard: [gfx-noted] → [gfx-noted][stockwell needswork]
I'll take a look at the log and see if I can figure out whether the changes in bug 1368286 tickled a pre-existing race condition, or if it's an actual regression from bug 1368286.
Flags: needinfo?(bugmail)
There are other regressions being reported from bug 1368286. It sounds like there's a bug in that code.
Blocks: 1368286
See Also: → 1369123
I also see in the logs bug 1300275 showing up (gfx/layers/apz/test/mochitest/test_interrupted_reflow.html | Test timed out.)
See Also: → 1300275
This (and bug 1300275) went away with the backout of bug 1368286. If it comes back with the updated version of that patch I'll investigate. Clearing ni for now.
Flags: needinfo?(bugmail)
Whiteboard: [gfx-noted][stockwell needswork] → [gfx-noted][stockwell fixed:backout]
I verified by testing on the try server that my upcoming patch for bug 1368286 doesn't bring this intermittent back.
Bulk priority update of open intermittent test failure bugs. 

P3 => P5

https://bugzilla.mozilla.org/show_bug.cgi?id=1381960
Priority: P3 → P5
This failure seems to happen because the helper_bug1346632.html is supposed to trigger a scroll (by simulating a user mouse-drag of the scrollbar) but for some reason the scroll doesn't happen. According to the screenshots the scrollbar is still at the top of the track indicating the attempt to scroll the bar failed.
There are 33 failures present on this bug over the last 7 days, these happen on linux64-qr and linux32.

Here is the most recent log example: https://treeherder.mozilla.org/logviewer.html#?job_id=190769558&repo=mozilla-central&lineNumber=6244

[task 2018-07-29T11:02:18.861Z] 11:02:18     INFO - TEST-UNEXPECTED-FAIL | gfx/layers/apz/test/mochitest/test_group_mouseevents.html | Test timed out.
Flags: needinfo?(bugmail)
I'm investigating
Assignee: nobody → bugmail
Flags: needinfo?(bugmail)
I reproduced this locally; what seems to be happening is that we synthesize mousedown, mousemove, mouseup events in order to simulate a drag, but the OS reorders the events and sends us OnButtonPressEvent, OnButtonReleaseEvent, OnMotionNotifyEvent. So then we send those through to APZ and it doesn't do a drag because there are no move events in between the mousedown and mouseup. Possible fixes include (a) modifying the test to delay more before synthesizing the mouseup, or (b) modifying the gtk widget code to dispatch a mousemove if it gets a OnButtonReleaseEvent that's at a different location than the OnButtonPressEvent, or (c) modifying the APZ drag code to drag to the mouse-up position before ending the drag, or (d) see if there's a better way to synthesize the mousemove that doesn't result in this out-of-order behaviour.
Comment on attachment 8996049 [details]
Bug 1368603 - Fix intermittent scrollbar drag test failure on Linux.

Jumped the gun on that. This patch breaks it on Windows, looks like.
Attachment #8996049 - Flags: review?(botond)
Comment on attachment 8996049 [details]
Bug 1368603 - Fix intermittent scrollbar drag test failure on Linux.

https://reviewboard.mozilla.org/r/260304/#review267650

Thanks for looking into this!

::: gfx/layers/apz/test/mochitest/apz_test_native_event_utils.js:350
(Diff revision 2)
>  
>  // Synthesizes events to drag |element|'s vertical scrollbar by the distance
>  // specified, synthesizing a mousemove for each increment as specified.
> -// Returns false if the element doesn't have a vertical scrollbar, or true after
> -// all the events have been synthesized.
> +// Returns false if the element doesn't have a vertical scrollbar. Otherwise,
> +// returns a generator that should be invoked after the mousemoves have been
> +// processed, to end the scrollbar drag.

Please mention _how_ the caller is supposed to wait for the mousemoves to be processed. (Even if it's "any way you want", it's helpful to mention waiting for a scroll event as an example.)
Attachment #8996049 - Flags: review?(botond) → review+
Comment on attachment 8996049 [details]
Bug 1368603 - Fix intermittent scrollbar drag test failure on Linux.

https://reviewboard.mozilla.org/r/260304/#review267650

> Please mention _how_ the caller is supposed to wait for the mousemoves to be processed. (Even if it's "any way you want", it's helpful to mention waiting for a scroll event as an example.)

Updated comment accordingly.
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2f559b8b0aa3
Fix intermittent scrollbar drag test failure on Linux. r=botond
https://hg.mozilla.org/mozilla-central/rev/2f559b8b0aa3
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63

Kats, can you rebase this on esr60 to fix the gfx/layers/apz/test/mochitest/test_group_mouseevents.html failures, as suggested on IRC? Thank you. See bug 1527089.

Flags: needinfo?(kats)

Posted a try push with my best attempt on bug 1527089. Not sure if it will work though, a lot has changed since ESR 60 and the rebase wasn't clean.

Flags: needinfo?(kats)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: