Closed Bug 506187 Opened 15 years ago Closed 12 years ago

Intermittent test_wheeltransaction.xul | wrong view was scrolled: Reset transaction by a mouse move event (h-9) - "rootview" should equal "subview1"

Categories

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

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mfinkle, Unassigned)

References

Details

(Keywords: intermittent-failure)

WINNT 5.2 mozilla-central unit test on 2009/07/23 19:41:15

8153 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/widget/tests/test_wheeltransaction.xul | wrong view was scrolled: Reset transaction by a mouse move event (h-9) - got "rootview", expected "subview1"

This happened during a build that affected Linux only:
http://hg.mozilla.org/mozilla-central/rev/4f202bc59656
Blocks: 438871
Whiteboard: [orange]
I've done some analysis of this failure.  The particular test that failed here is trying to assert that during a series of mouse wheel events, a mouse movement after mousewheel.transaction.ignoremovedelay ms will cause the transaction to be reset.  mousewheel.transaction.ignoremovedelay defaults to 100ms; the test tries to fire a mouse move event after 120ms to trigger the transaction reset.

The problem is that setTimeout() is not accurate enough for this case.  I added some debug code to the test and ran it a number of times.  The code shows me the value passed to setTimeout(), and the actual delay before the setTimeout callback is triggered.  In the case of this test where the delay is 120ms, actual values I received ranged from 105ms to over 400ms.  Since the test needs to trigger an event after 100+ms, I can see how there is a chance that this would fail because the setTimeout() callback gets triggered in less than 100ms, at least rarely.

There are two possible solutions: update the test to use a 200ms timeout instead of a 120ms timeout, or add the canFailRandomly element to the test (see bug 491712).  In the latter case, if the test fails, it would automatically be re-run with a 1200ms timeout vs the original 120ms timeout.
Thank you, Jonathan.

(In reply to comment #1)
> There are two possible solutions: update the test to use a 200ms timeout
> instead of a 120ms timeout, or add the canFailRandomly element to the test (see
> bug 491712).  In the latter case, if the test fails, it would automatically be
> re-run with a 1200ms timeout vs the original 120ms timeout.

I think that the case is very rare. And the former can remain the possibility (but maybe it's most 0%), so, I think the latter is enough for this case. I'll post the patch ASAP. (Or, if you hurry, please post the patch yourself, it's welcome.)
Version: unspecified → Trunk
(In reply to comment #3)
> Pushed test fix described above as
> http://hg.mozilla.org/mozilla-central/rev/ed13a1ebb1d0

Thank you for your work.
# Timeout test (v-5) and Timeout test (h-5) might also need same code, but it shouldn't be so. The margin should be enough...
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1252103578.1252110656.31855.gz
OS X 10.5.2 mozilla-central unit test on 2009/09/04 15:32:58
{
... | wrong view was scrolled: Reset transaction by a mouse move event (v-9) - got "subview2", expected "subview1"
}
Summary: test_wheeltransaction.xul UNEXPECTED-FAIL → mochitest-chrome: intermittent test_wheeltransaction.xul UNEXPECTED-FAIL
Shame on me for not fixing the summary the first time I starred this, to prevent comment 13 through comment 20. Filed bug 676470 for the crash regression that landed on inbound around July 21st.
Summary: mochitest-chrome: intermittent test_wheeltransaction.xul UNEXPECTED-FAIL → Intermittent test_wheeltransaction.xul | wrong view was scrolled: Reset transaction by a mouse move event (h-9) - "rootview" should equal "subview1"
Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that:
* Haven't changed in > 6months
* Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb}
* Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive.

I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases).

Sorry for the spam! Filter on: #FFA500
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange]
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.