Closed Bug 1137952 Opened 9 years ago Closed 9 years ago

Intermittent test_bug607464.html | Pixel scrolling should have finished after one refresh driver iteration. We shouldn't be scrolling smoothly, even though the pref is set. - got 0, expected 15


(Core :: DOM: UI Events & Focus Handling, defect)

39 Branch
Not set



Tracking Status
firefox37 --- fixed
firefox38 --- fixed
firefox39 --- fixed
firefox-esr31 --- fixed
b2g-v2.1 --- fixed
b2g-v2.1S --- fixed
b2g-v2.2 --- fixed
b2g-master --- fixed


(Reporter: KWierso, Assigned: kats)



(Keywords: intermittent-failure)


(1 file, 1 obsolete file)

12:46:23 INFO - 244 INFO TEST-START | dom/events/test/test_bug605242.html
12:46:23 INFO - 245 INFO TEST-OK | dom/events/test/test_bug605242.html | took 46ms
12:46:23 INFO - 246 INFO TEST-START | dom/events/test/test_bug607464.html
12:46:23 INFO - 247 INFO must wait for load
12:46:23 INFO - 248 INFO must wait for focus
12:46:23 INFO - 249 INFO TEST-UNEXPECTED-FAIL | dom/events/test/test_bug607464.html | Pixel scrolling should have finished after one refresh driver iteration. We shouldn't be scrolling smoothly, even though the pref is set. - got 0, expected 15
12:46:23 INFO - 250 INFO MEMORY STAT vsize after test: 3423588352
12:46:23 INFO - 251 INFO MEMORY STAT residentFast after test: 390557696
12:46:23 INFO - 252 INFO MEMORY STAT heapAllocated after test: 151905120
12:46:23 INFO - 253 INFO TEST-OK | dom/events/test/test_bug607464.html | took 398ms
12:46:23 INFO - 254 INFO TEST-START | dom/events/test/test_bug613634.html
Any ideas what might be going on here?
Flags: needinfo?(bzbarsky)
Flags: needinfo?(bugs)
Presumably someone broke something?  This test hasn't changed since bug 1056851, which landed a week before the failures started, right?
Flags: needinfo?(bzbarsky)
I strongly suspect bug 1137203 given timing of when it hit the various branches (which of course we wouldn't have caught on b2g-inbound since 10.8 tests don't run there).

BTW, why are we landing GFX patches on b-i?!?!?
Flags: needinfo?(bugs) → needinfo?(bugmail.mozilla)
Bug 1137203 backed out - we'll find out soon enough.
I can reproduce this locally, and as far as I can tell it seems to be a pre-existing race condition in the code. It may very well have been exposed by my patches on bug 1137203, or by something else, who knows. The test is for bug 607464, which tested that wheel scroll events of type PIXEL don't trigger smooth scrolling. However, when I instrument the code I see that now these wheel scroll events are in fact triggering SMOOTH_MSD scrolling. Sometimes the scrolling finishes before the test checks for the scroll position, and sometimes it doesn't, resulting in the intermittent failure.

Either the code is correct and we are supposed to use SMOOTH_MSD for PIXEL wheel events, in which case the test is wrong. Or the code is wrong and we should be using an INSTANT scroll in this case. Kip, Markus - do you know which of the two is applicable here?
Flags: needinfo?(mstange)
Flags: needinfo?(kgilbert)
Flags: needinfo?(bugmail.mozilla)
Sorry, I was wrong - I misread some of the output. It's not doing SMOOTH_MSD scrolling after all, it's doing NORMAL scrolling which uses an mAsyncScroll thingy. Maybe it's just the async-ness of the scrolling that isn't properly detected by the test.
Flags: needinfo?(kgilbert)
(In reply to Kartikaya Gupta ( from comment #69)
> Maybe it's just the async-ness of the scrolling that isn't properly
> detected by the test.

This is very much possible. Somebody needs to find out what kinds of async-ness scrolling uses and how the test can wait for it reliably.
I think these things all used to go through the refresh driver - the test was apparently fairly stable for a few years. So it looks like one step in the async-ness chain has changed to something else.
Flags: needinfo?(mstange)
Attached patch PatchSplinter Review
Doh, this looks like a typo. This patch seems to fix it for me locally, and I did a try push for 10.8 to verify.
Assignee: nobody → bugmail.mozilla
Attachment #8571487 - Flags: review?(mstange)
Comment on attachment 8571487 [details] [diff] [review]

This again! Argh!

Nice job catching it. I didn't realize this test was opening new windows, or I would have suggested for looking something like it, because I've wasted a whole day on a very similar problem before (see the last paragraph of bug 1112339 comment 0).
Attachment #8571487 - Flags: review?(mstange) → review+
Try build is still pending and I don't know if it'll ever get scheduled, so I pushed to inbound anyway. Even if it doesn't fix the problem it's still a correct change.
The try push from comment 71 is green, which indicates that this was the root cause of the M-2 failure that got bug 1137203 backed out. I've relanded those now, but this patch will need uplifting to b2g34 and b2g37 so that bug 1137203 can also get uplifted. I intend to do that with a=testonly once this merges to m-c.
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
I was going to land this on beta and let it merge, but oh well.
Assignee: bugmail.mozilla → cpearce
Assignee: cpearce → bugmail.mozilla
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.