491712 - Sporadic failure in test_wheeltransaction.xul

Status: RESOLVED FIXED

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

Description

[Daniel Holbert [:dholbert]]

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)

Comment 1

[Daniel Holbert [:dholbert]]

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. :)

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

I hope bug 486502 didn't cause this somehow.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Let's keep this open.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v1.0

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.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

(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?

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(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

[Olli Pettay [:smaug][[e-mail]]]

(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?

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(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

[Olli Pettay [:smaug][[e-mail]]]

(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.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(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

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 379097 [details] [diff] [review]
Patch v1.0

I guess that means we don't just bypass some tests.

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(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.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

http://hg.mozilla.org/mozilla-central/rev/01e14fa57337