Closed Bug 518274 Opened 17 years ago Closed 14 years ago

reftest: dynamic--inline-resize-window-width.xhtml intermittently fails

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: MatsPalmgren_bugz, Unassigned)

References

(
URL
)

Details

(Keywords: intermittent-failure)

Bug 509274 fixed this, but added 5 second timeouts for each test. Bug 517744 removed the timeouts, but kept the "MozReftestInvalidate" handlers. Unfortunately, that brought back the original problem with intermittent failures. See URL. We could backout bug 517744, but I would prefer a solution that doesn't add 35 seconds to the reftest run.
Whiteboard: [orange]
Relying on the setTimeout(..., 0) could be the issue here. The re-layout due to restoring the window size and the removal or the 'class' attribute both happen off events that are both in the event loop at the same time, but there's no guarantee which order these will be evaluated in. Pushed http://hg.mozilla.org/mozilla-central/rev/a99faa2257da to see if that fixes.
I wonder if we should be using mozAfterPaint rather than mozReftestInvalidate the second time?
I'm not sure. Maybe roc knows.
We shouldn't put the removal of reftest-wait in a setTimeout. That should not be needed and just adds nondeterminism. After reftest-wait is removed, reftest.js automatically flushes reflows and then waits for all invalidates to be notified via MozAfterPaint before it stops the test. So I don't know why this isn't working. (In reply to comment #1) > Pushed http://hg.mozilla.org/mozilla-central/rev/a99faa2257da to see if that > fixes. How does this work? It seems the test won't complete until we get two MozReftestInvalidate events, which won't happen.
(In reply to comment #4) > How does this work? It seems the test won't complete until we get two > MozReftestInvalidate events, which won't happen. I wondered about that, but the test passed rather than timing out when I did a test run with that change so I assumed we get repeated MozReftestInvalidate events. :-/ Weird. Dunno how it would pass if we only get one. On taking another look, it looks like the real race was coming from the fact that the body has an onload calling resize_height (as well as having the MozReftestInvalidate addEventListener call it). The onload call would have caused the setTimeout(..., 0) to be called to finish the test before MozReftestInvalidate had been fired. Pushed: http://hg.mozilla.org/mozilla-central/rev/be16bcab1786
Actually I think these 'window' tests are bogus. Setting innerWidth/Height silently fails for non-privileged content IIRC. Filed bug 518311 about that.
wouldn't these tests work just as well if the <svg> was in a block element that we resize with CSS?
There are already other tests that do exactly that, and tests using iframe. I added these 'window' tests because we were failing specifically in that case at one point.
The test failed again: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1253747631.1253755588.12126.gz Linux mozilla-central unit test on 2009/09/23 16:13:51
Blocks: 438871
Version: unspecified → Trunk
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1253830360.1253832774.32522.gz Linux mozilla-central test opt everythingelse on 2009/09/24 15:12:40
This test has been orange on the "Linux mozilla-central test opt everythingelse" tinderbox for the last 9 cycles or so.
Good call, thanks. I would have done it myself but I was on a long haul flight and missed the orange madness. I probably won't get to investigating this properly until after the SVG WG F2F and SVG Open conf, and I've not managed to reproduce the failure locally.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1261179730.1261181707.6968.gz Linux mozilla-1.9.1 test everythingelse on 2009/12/18 15:42:10
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.