Closed
Bug 491712
Opened 16 years ago
Closed 16 years ago
Sporadic failure in test_wheeltransaction.xul
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: dholbert, Assigned: masayuki)
References
()
Details
(Keywords: intermittent-failure)
Attachments
(1 file)
(deleted),
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
This mochitest-chrome test just failed:
*** 2155 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-3) - got "subview1", expected "rootview"
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1241614679.1241623545.11790.gz
WINNT 5.2 mozilla-central unit test on 2009/05/06 05:57:59
This appears to be sporadic, because the two previous cycles were built from the same changeset, and they passed this test. (though they had other known-sporadic failures)
Reporter | ||
Updated•16 years ago
|
Whiteboard: [orange]
Reporter | ||
Comment 1•16 years ago
|
||
Actually, this looks like a dupe of bug 485994 -- my bug-searches didn't find it before because it's RESOLVED|FIXED, but it looks like it needs reopening. :)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Comment 2•16 years ago
|
||
I hope bug 486502 didn't cause this somehow.
Comment 3•16 years ago
|
||
Let's keep this open.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee | ||
Comment 4•16 years ago
|
||
adding |canFailRandomly: { possibleView: gSubView1 },| to testOneTimeScroll which offset is in gSubView1 but expectedView is another.
And also adding |canFailRandomly: { possibleView: gRootView },| to testOneTimeScroll which expectedView is null but gRootView can be scrolled if it's timed-out.
These changes should fix this random failures.
Assignee: nobody → masayuki
Status: REOPENED → ASSIGNED
Attachment #379097 -
Flags: review?(Olli.Pettay)
Comment 5•16 years ago
|
||
(In reply to comment #4)
> adding |canFailRandomly: { possibleView: gSubView1 },| to testOneTimeScroll
> which offset is in gSubView1 but expectedView is another.
Do you know why expectedView isn't the right one?
Assignee | ||
Comment 6•16 years ago
|
||
(In reply to comment #5)
> (In reply to comment #4)
> > adding |canFailRandomly: { possibleView: gSubView1 },| to testOneTimeScroll
> > which offset is in gSubView1 but expectedView is another.
> Do you know why expectedView isn't the right one?
If the test is delayed, the test can be timeout. Then the test is failed by the possible view scrolling.
Comment 7•16 years ago
|
||
(In reply to comment #6)
> If the test is delayed, the test can be timeout.
What do you mean with this? Can't you detect somehow that the test is delayed?
Assignee | ||
Comment 8•16 years ago
|
||
(In reply to comment #7)
> (In reply to comment #6)
> > If the test is delayed, the test can be timeout.
> What do you mean with this? Can't you detect somehow that the test is delayed?
No, I have no idea to detect the delay.
If the test was delayed (e.g., by another processes eat CPU or something resource), then, this unexpected failure happens.
The tests test continuation of one transaction. I.e., the tests test whether they are finished or not by the previous action. But if the tests are not tested during expected timing, the tests are failed by timeout. At that time, the possibleViews are scrolled.
If a test is failed by the possibleView, the tests are re-tested with longer transaction timeout settings.
So, if an environment is very slow for long time by some reasons, the tests cannot finish correctly.
Comment 9•16 years ago
|
||
(In reply to comment #8)
> If a test is failed by the possibleView, the tests are re-tested with longer
> transaction timeout settings.
Ah, so in this case there are no failures.
Assignee | ||
Comment 10•16 years ago
|
||
(In reply to comment #9)
> (In reply to comment #8)
> > If a test is failed by the possibleView, the tests are re-tested with longer
> > transaction timeout settings.
> Ah, so in this case there are no failures.
Yes. It fixes the random failures.
Comment 11•16 years ago
|
||
Comment on attachment 379097 [details] [diff] [review]
Patch v1.0
I guess that means we don't just bypass some tests.
Attachment #379097 -
Flags: review?(Olli.Pettay) → review+
Assignee | ||
Comment 12•16 years ago
|
||
(In reply to comment #11)
> (From update of attachment 379097 [details] [diff] [review])
> I guess that means we don't just bypass some tests.
Yes, I don't bypass. They just retry the tests 5 times in worst case. If all times they are failed, it becomes orange.
Assignee | ||
Comment 13•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Keywords: intermittent-failure
Updated•12 years ago
|
Whiteboard: [orange]
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•