Closed Bug 858737 Opened 11 years ago Closed 11 years ago

Intermittent test_bug569520.html | Second listener should fire after first listener

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
All
Windows 8
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla26
Tracking Flags:
Tracking Status
firefox24 --- fixed
firefox25 --- fixed
firefox26 --- fixed

People

(Reporter: RyanVM, Assigned: avih)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Check monotonic arg using unprefixed rAF and add some slack to the prefixed version
2.31 KB, patch
roc
: review+
Details | Diff | Splinter Review 
https://tbpl.mozilla.org/php/getParsedLog.php?id=21482312&tree=Mozilla-Inbound

WINNT 6.2 mozilla-inbound debug test mochitest-4 on 2013-04-05 04:59:18 PDT for push 722d438e1072
slave: t-w864-ix-014

12:17:00     INFO -  16799 INFO TEST-START | /tests/layout/base/tests/test_bug569520.html
12:17:00     INFO -  ++DOMWINDOW == 280 (1BB4D7A8) [serial = 1752] [outer = 0E5C7E78]
12:17:00     INFO -  16800 INFO TEST-PASS | /tests/layout/base/tests/test_bug569520.html | Bogus animation start time
12:17:00     INFO -  16801 INFO TEST-PASS | /tests/layout/base/tests/test_bug569520.html | First listener should fire after start
12:17:00     INFO -  16802 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/base/tests/test_bug569520.html | Second listener should fire after first listener
12:17:00     INFO -  16803 INFO TEST-END | /tests/layout/base/tests/test_bug569520.html | finished in 228ms
See bug 793735 where Gabriele has found some pretty funky timer/clock behavior in Windows 8 as part of rewriting the startup timeline code.
These failures are way too sparse to declare them as bugs IMO. I'm guessing they correlate to some intermittent states of the code and have been taken care of already.

The failure is essentially this code:

//---------------
var t1;

function first(t) {
  t1 = t;
  mozRequestAnimationFrame(second);
}

function second(t2) {
  ok(t2 >= t1, "Second listener should fire after first listener");
}

addLoadEvent(
  function() (
    setTimeout(function() { mozRequestAnimationFrame(first); }, 100);
  }
);
//---------------


I believe that rAF provides the timestamp via JS_Now().

Honza, as far as you know, do the failure dates correlate to some work which might have temporarily caused JS_Now() to return non-monotonic values? How about TimeStamp::Now() ?

One Win8 failure at 2013-04-05.
One Win7 failure at 2013-06-19.
Flags: needinfo?(honzab.moz)
Closing for now, assuming it was intermittent and got fixed. Let's reopen if it returns.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(honzab.moz)
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
While it fails relatively rarely, this thing doesn't really seem to go away either. Not sure how much resources we wanna put into debugging it.

Since bz wrote that test, I wanted to mark him for needinfo, but I can't seem to find him on bugzilla today...
(In reply to Avi Halachmi (:avih) from comment #9)
> Since bz wrote that test, I wanted to mark him for needinfo, but I can't
> seem to find him on bugzilla today...

I think bz's on vacation until next week, so it might take a while to get a response.
Flags: needinfo?(bzbarsky)
I recommend switching to requestAnimationFrame, which provides monotonic time as argument, not wall-clock time.
Flags: needinfo?(bzbarsky)
Avi, were you volunteering to make the change? :)
Flags: needinfo?(avihpit)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #18)
> Avi, were you volunteering to make the change? :)

But of course ;)

According to bz (on irc), the last change to mozRequestAnimationFrame was on Dec 2012 on bug 731974. Right now the argument it's called back with isn't enforced to be monotonic, which explains the occasional failures.

The thing which isn't explained is why we didn't get any failures before 2013-04-05. I'd attribute that either to luck or that the failures weren't logged on this bug.

So I'll follow the suggestion from comment 15 and land it soon.
Flags: needinfo?(avihpit)
Depends on: 909154
AFAIK the only test which failed is the one which checks that 2 consecutive callback args from mozRequestAnimationFrame are monotonic.

I replaced this test to use the non prefixed requestAnimationFrame which should be monotonic.

However, since the prefixed version is still used at the code (76 instances on m-c, and probably more on other trees), and it's yet to be determined if we remove support for it (bug 909154) I've kept the 2 other tests of the prefixed version, and also added some slack by checking monotonicity after 3 consecutive callbacks rather than after one (even if the original test didn't seem to fail with one).

This way at we'll be testing something with the prefixed version.
Attachment #795211 - Flags: review?(roc)
https://hg.mozilla.org/mozilla-central/rev/e72c1ed06304
Assignee: nobody → avihpit
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: