Closed Bug 984821 Opened 10 years ago Closed 9 years ago

Intermittent browser_CTP_iframe.js | Test 1, Waited too long for the overlay to become invisible.

Categories

(Core Graveyard :: Plug-ins, defect)

x86
macOS
defect
Not set
normal

Tracking

(e10s+, firefox37 wontfix, firefox38 disabled, firefox39 disabled, firefox40 disabled, firefox41 disabled, firefox42 fixed, firefox-esr31 unaffected, firefox-esr38 disabled)

RESOLVED FIXED
mozilla42
Tracking Status
e10s + ---
firefox37 --- wontfix
firefox38 --- disabled
firefox39 --- disabled
firefox40 --- disabled
firefox41 --- disabled
firefox42 --- fixed
firefox-esr31 --- unaffected
firefox-esr38 --- disabled

People

(Reporter: cbook, Assigned: rowbot)

References

(Blocks 1 open bug, )

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Rev4 MacOSX Snow Leopard 10.6 mozilla-central opt test mochitest-browser-chrome on 2014-03-17 23:39:24 PDT for push 89275f0ae29f

slave: talos-r4-snow-098

https://tbpl.mozilla.org/php/getParsedLog.php?id=36317145&tree=Mozilla-Central



TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/plugins/browser_CTP_iframe.js | Test 1, Waited too long for the overlay to become invisible.
This shows a clear spike after bug 899347 landed. Mike, can you please look into this failure?
Flags: needinfo?(mconley)
Yeah, I can look at this.
Assignee: nobody → mconley
Flags: needinfo?(mconley)
What's going on here is that we're finding and clicking the closeIcon element of the plugin binding before it tries to make itself visible.

So we click it, we make it invisible, and then the code to make it visible runs, and then the test spins waiting for the binding to make itself invisible, and then we fail.

I think this is the result of us not waiting for a test to fully finish / teardown before starting the next one.
While I know the eventual cause of this intermittent, I haven't yet found the root cause. Still looking.
Started to dig into this again. I've determined that, at least on my Windows 7 debug build, I only need to run the following subset of the tests in that folder to fail:

[browser_bug744745.js]
[browser_bug787619.js]
[browser_CTP_iframe.js]
Comment on attachment 8530478 [details] [diff] [review]
Fix intermittent orange caused by fast loading and unloading of content with plugins. r=?

What are your thoughts on this gfritzsche? It's a bit hacky, but it might do as a bandaid until bug 1074983 gets fixed.
Attachment #8530478 - Flags: review?(georg.fritzsche)
Comment on attachment 8530478 [details] [diff] [review]
Fix intermittent orange caused by fast loading and unloading of content with plugins. r=?

Review of attachment 8530478 [details] [diff] [review]:
-----------------------------------------------------------------

If the issue is with not waiting on a previous test finalizing its state, can't we fix that instead of tacking more workarounds on?
Or do you think there is a real-world concern here?
(In reply to Georg Fritzsche [:gfritzsche] from comment #475)
> Comment on attachment 8530478 [details] [diff] [review]
> Fix intermittent orange caused by fast loading and unloading of content with
> plugins. r=?
> 
> Review of attachment 8530478 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> If the issue is with not waiting on a previous test finalizing its state,
> can't we fix that instead of tacking more workarounds on?
> Or do you think there is a real-world concern here?
Flags: needinfo?(mconley)
Comment on attachment 8530478 [details] [diff] [review]
Fix intermittent orange caused by fast loading and unloading of content with plugins. r=?

Cancelling review while waiting on the open question above.
Attachment #8530478 - Flags: review?(georg.fritzsche)
Yeah, I think you're right. I think the better solution probably lies in bug 1074983.
Flags: needinfo?(mconley)
Any news here or should we just bite the bullet and disable?
Flags: needinfo?(mconley)
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #660)
> Any news here or should we just bite the bullet and disable?

No news as of yet - been bogged down by other things. I'm actually getting back into click-to-play stuff now with bug 1110887, so I might be able to swing by and fix bug 1074983 (which should fix this) while I'm at it.

Give me a few more weeks?
Flags: needinfo?(mconley)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #662)
> Give me a few more weeks?

It's been more than a few weeks now. I plan to disable soon. Let me know if you object.
Flags: needinfo?(mconley)
My only objection is that jimm's patch in bug 1129040 (currently in the review phase) is set to re-write this test, and might address this orange. You can disable it, but we should probably re-enable it once bug 1129040 lands.
Flags: needinfo?(mconley) → needinfo?(ryanvm)
Does that sound agreeable?
I think verifying stability and re-enabling as part of 1129040 makes perfect sense. Leaving the ni? set to keep it on my radar for disabling for now.

Note that I plan to disable this on 38/39 as well.
Depends on: 1129040
https://hg.mozilla.org/mozilla-central/rev/04bf57cd1b6e
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Disabled on Linux and OSX.

https://hg.mozilla.org/releases/mozilla-aurora/rev/2eecf1fbd302
Status: RESOLVED → REOPENED
Flags: needinfo?(ryanvm)
Resolution: FIXED → ---
Whiteboard: [test disabled on Linux and OSX][leave open]
Target Milestone: mozilla40 → ---
Bug 1161564 has been filed to re-enable the test now that bug 1129040 has closed.
Bug 1161564 re-enabled this test on MacOSX and Linux nearly a month ago and this intermittent doesn't seem to have returned.  Marking this as fixed.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Whiteboard: [test disabled on Linux and OSX][leave open]
Assignee: mconley → smokey101stair
Target Milestone: --- → mozilla42
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: