Closed
Bug 1368603
Opened 8 years ago
Closed 7 years ago
Intermittent gfx/layers/apz/test/mochitest/test_group_mouseevents.html | Test timed out.
Categories
(Core :: Panning and Zooming, defect, P5)
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)
Assignee | ||
Updated•8 years ago
|
OS: Unspecified → Linux
Priority: -- → P3
Hardware: Unspecified → x86_64
Whiteboard: [gfx-noted]
Version: unspecified → 55 Branch
Comment hidden (Intermittent Failures Robot) |
Comment 2•8 years ago
|
||
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.
Comment 3•8 years ago
|
||
thanks for narrowing this down :ryanvm
Whiteboard: [gfx-noted] → [gfx-noted][stockwell needswork]
Assignee | ||
Comment 4•8 years ago
|
||
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)
Assignee | ||
Comment 5•8 years ago
|
||
There are other regressions being reported from bug 1368286. It sounds like there's a bug in that code.
Comment hidden (Intermittent Failures Robot) |
Comment 7•8 years ago
|
||
I also see in the logs bug 1300275 showing up (gfx/layers/apz/test/mochitest/test_interrupted_reflow.html | Test timed out.)
Assignee | ||
Comment 8•8 years ago
|
||
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)
Updated•8 years ago
|
Whiteboard: [gfx-noted][stockwell needswork] → [gfx-noted][stockwell fixed:backout]
Comment 9•8 years ago
|
||
I verified by testing on the try server that my upcoming patch for bug 1368286 doesn't bring this intermittent back.
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 16•7 years ago
|
||
Bulk priority update of open intermittent test failure bugs.
P3 => P5
https://bugzilla.mozilla.org/show_bug.cgi?id=1381960
Priority: P3 → P5
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 27•7 years ago
|
||
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.
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 59•7 years ago
|
||
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)
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 61•7 years ago
|
||
I'm investigating
Assignee: nobody → bugmail
Flags: needinfo?(bugmail)
Assignee | ||
Comment 62•7 years ago
|
||
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.
Assignee | ||
Comment 63•7 years ago
|
||
Assignee | ||
Comment 64•7 years ago
|
||
Comment hidden (mozreview-request) |
Assignee | ||
Comment 66•7 years ago
|
||
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)
Assignee | ||
Comment 67•7 years ago
|
||
Silly mistake. This should be better:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4ff3665439cdb1fc8e0cd7895f2b3d406725e40a
Comment hidden (mozreview-request) |
Comment 69•7 years ago
|
||
mozreview-review |
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+
Assignee | ||
Comment 70•7 years ago
|
||
mozreview-review-reply |
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.
Comment hidden (mozreview-request) |
Comment 72•7 years ago
|
||
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2f559b8b0aa3
Fix intermittent scrollbar drag test failure on Linux. r=botond
Comment 73•7 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox63:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
![]() |
||
Comment 77•6 years ago
|
||
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)
Assignee | ||
Comment 78•6 years ago
|
||
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.
Description
•