Closed Bug 1040724 Opened 11 years ago Closed 11 years ago

Intermitten test_visibility.html | Plugin should have painted once. (expected 1 independent paints, expected 1 logged paints, got 2 actual paints)

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox32 unaffected, firefox33 disabled, firefox34 fixed, firefox-esr24 unaffected, firefox-esr31 unaffected)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox32 --- unaffected
firefox33 --- disabled
firefox34 --- fixed
firefox-esr24 --- unaffected
firefox-esr31 --- unaffected

People

(Reporter: cbook, Unassigned)

References

(
URL
)

Details

(Keywords: intermittent-failure)

Ubuntu VM 12.04 x64 mozilla-inbound debug test mochitest-other on 2014-07-18 00:47:42 PDT for push 8e453205ddbf slave: tst-linux64-spot-1069 https://tbpl.mozilla.org/php/getParsedLog.php?id=44088802&tree=Mozilla-Inbound 352 INFO TEST-UNEXPECTED-FAIL | /tests/dom/plugins/test/mochitest/test_visibility.html | Plugin should have painted once. (expected 1 independent paints, expected 1 logged paints, got 2 actual paints)
This is insanely frequent (as in, nearly perma-fail). We need a fix or a backout here ASAP.
Flags: needinfo?(georg.fritzsche)
Do you have a suspected regression window here? I don't have an idea on recent patches that may affect this, maybe gfx or e10s work?
Flags: needinfo?(georg.fritzsche) → needinfo?(sheriffs)
I think this is a gfx issue, not entirely sure. pinging @roc: When the test fails, we're running | plugin.style.visibility = 'visible' | in onload, then getting two paints from the refresh driver for the nsObjectFrame, expecting one. If we set a non-zero timeout before changing visibility, the problem stops reproducing. If we do a setTimeout(0) in onload to set visibility, it reproduces much more readily. There are never extra paints before the style change. If you add a timeout between the plugin painting and firing the next step of the test, there's no change. E.g. it doesn't seem we're racing with the refresh driver after the style change call.
Flags: needinfo?(roc)
does it help/make a difference if you use paint_listener.js and use waitForAllPaintsFlushed to trigger startTest?
Flags: needinfo?(roc)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #127) > does it help/make a difference if you use paint_listener.js and use > waitForAllPaintsFlushed to trigger startTest? It does not, however, this stopped happening on m-c! Bisected to: > http://hg.mozilla.org/mozilla-central/rev/0d3378b935d7 > Author: Matt Woodrow <mwoodrow@mozilla.com> > Date: Wed Jul 23 10:53:37 2014 +1200 > > Bug 961249 - Don't propagate component alpha layer flattening across force active layers and avoid unnecessary invalidations. r=roc @roc do you think this was a symptom of that bug, or did it just wallpaper over it?
Flags: needinfo?(roc)
It sounds plausible that that change fixed this bug, but it's hard to be sure. It's plausible enough to close this bug though :-).
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(sheriffs)
Flags: needinfo?(roc)
Resolution: --- → WORKSFORME
What does that mean for Aurora, which is also affected by this?
status-firefox32: --- → unaffected
status-firefox33: --- → affected
status-firefox34: --- → fixed
status-firefox-esr24: --- → unaffected
status-firefox-esr31: --- → unaffected
Flags: needinfo?(roc)
Probably just disable this test on Aurora.
Flags: needinfo?(roc)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.