Closed Bug 781482 Opened 8 years ago Closed 8 years ago
Plugins in dead/zombie compartments continue to play
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 Build ID: 20120808030529 Steps to reproduce: It is a recent regression since 20120808 build and a different issue from bug 778318. I think it is a Nightly bug rather than an extension's or userscript's. Flash: 11.3.300.268 or 11.3.300.270 Greasemonkey 0.9.22 or Scriptish 0.1.7 (any combinations will reproduce the bug) YousableTubeFix 2012.6.9 (https://userscripts.org/scripts/show/13333) 1. In a new profile, install Greasemonkey 0.9.22 or Scriptish 0.1.7 and YTF 2012.6.9. Keep the default settings. 2. Open any youtube video page, e.g. http://www.youtube.com/watch?v=E88d4e1gYh0. 3. While the video is still playing, close the page. Actual results: The video is still downloading and playing even though the tab is closed. A ghost window of the page is reported at about:compartments. Expected results: No ghost windows is created like 20120807 build or earlier. Note: 1. If you have multiple youtube pages opened, ghost windows are shown only if all those pages are closed. 2. Killing plugin-container.exe kills the ghost windows. YousableTubeFix's author is notified via https://userscripts.org/topics/115224.
> 1. If you have multiple youtube pages opened, ghost windows are shown only if all those pages are > closed. This is a quirk of how ghost windows are designed. See http://jlebar.com/2012/5/30/A_ghost_story.html
This is interesting. The fact that videos keep playing is obviously a Firefox regression, which is presumably related to zombie compartments existing for those windows. What's more interesting, though, is that Greasemonkey Leaks the World seems to be back in spite of Kyle's fix.
Can we get a regression range here?
Not to blame everything on :johns, but the time window is right for this to be related to bug 745030, and it is plugin related...
This is almost definitely from bug 745030, though I think it should be a quick fix
Assignee: nobody → jschoenick
Status: UNCONFIRMED → ASSIGNED
Component: Untriaged → Plug-ins
Ever confirmed: true
OS: Windows 7 → All
Product: Firefox → Core
Hardware: x86_64 → All
Version: 17 Branch → Trunk
I wonder if we can add some kind of test based on YousableTubeFix, as it seems to be a good bellwether. ;)
BTW, this regression (i.e. audio keeps playing) is also observable if you have Flashblock 1.5.16 and you do the following: 1. visit nbcnews.com 2. click any video link that launches the video player popup 3. let the video start playing then close the video player window Audio continues to playing.
This happens due to a rebase error in applying bug 745030 that results in us not releasing the mIsStopping lock, preventing us from stopping plugins more than once per object. Oops. bug 745030 exposed some other start/stop race conditions that need to be resolved before the uplift, so I'm going to try to get bug 767635 landed next week to fix these issues, otherwise we'll need to backout 745030.
Depends on: 767635
So bug 778318 is the direct issue here, where the issue discussed here is related to plugins continuing to play in inactive documents. However, the plugin is still alive because the document is still alive, not vice versa. Additionally, since bug 767635 isn't ready yet, I'm going to try to just get this patch in 17, since backporting 767635 to aurora wont be desirable
Comment on attachment 650966 [details] [diff] [review] Fix rebase error in nsObjectLoadingContent Review of attachment 650966 [details] [diff] [review]: ----------------------------------------------------------------- I checked with John about clearing mStopping before the delayed stop early return and he says not doing it was intentional, that the delayed stop will result in the flag being cleared. That being the case, r+.
Attachment #650966 - Flags: review?(joshmoz) → review+
Using the current nightly builds, since August 8, 2012 I can go to cnn.com., msnbc,com, cbs.com, yuutube, many others. The current flsah (11.3.300.271) and I can open several TABs that contain videos. Start to play the first TAB and close the TAB while it is playing. The audio continues to play. Start the next video and the video plays and both audios play. U have gotten as far as four before the audio of the first completed. I can make this happen on demand. As it 'just do it'.
Comment on attachment 650966 [details] [diff] [review] Fix rebase error in nsObjectLoadingContent https://hg.mozilla.org/integration/mozilla-inbound/rev/69c5fcb15368 try: https://tbpl.mozilla.org/?tree=Try&rev=a16bc60ce498
Attachment #650966 - Flags: checkin+
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Confirmed with new Flash version 11.4.402.265 in Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120821135628 CSet: 1b51c7bf1e05 It doesn't happen in Namoroka, or even the latest Aurora as of 21 Aug 2012 on WinXP SP3. Since Ed Morley's fix is dated 22.08, I hope this means it'll be fixed in today's Nightly.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120822030558 CSet: abc17059522b I've just updated to the above-mentioned build, and the issue has, unfortunately, not been resolved. On the FF Forum, "Dingler" alluded to this bug. https://bugzilla.mozilla.org/show_bug.cgi?id=784070 In any case, I can confirm that even with today's Nightly update, if you run a Flash video and then close the tab, navigate away, or do pretty much anything besides close FF, the audio continues playing. I'm using 64-bit FF on Win 7 pro 64 bit. As stated, I'm also using the FlashBlock addon and the very latest version of the Flash plugin.
(In reply to Joe Greenman from comment #16) Wait one more Nightly since Comment 14 is not within today's Fixes (http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1b51c7bf1e05&tochange=abc17059522b).
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120823030518 CSet: 5650196a8c7d The fix worked on my machine. Thanks.
You need to log in before you can comment on or make changes to this bug.