781482 - Plugins in dead/zombie compartments continue to play

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Fanolian]

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.

Comment 1

[Justin Lebar (not reading bugmail)]

> 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

Comment 2

[Kris Maglione [:kmag]]

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.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Can we get a regression range here?

Comment 4

[Andrew McCreight [:mccr8]]

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...

Comment 5

[John Schoenick [:johns]]

This is almost definitely from bug 745030, though I think it should be a quick fix

Comment 6

[Andrew McCreight [:mccr8]]

I wonder if we can add some kind of test based on YousableTubeFix, as it seems to be a good bellwether. ;)

Comment 7

[IU]

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.

Comment 8

[John Schoenick [:johns]]

Attachment: Fix rebase error in nsObjectLoadingContent

Comment 9

[John Schoenick [:johns]]

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.

Comment 10

[John Schoenick [:johns]]

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 11

[Josh Aas]

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+.

Comment 12

[David]

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 13

[John Schoenick [:johns]]

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

Comment 14

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/69c5fcb15368

Comment 15

[u52928]

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.

Comment 16

[u52928]

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.

Comment 17

[(mostly gone) XtC4UaLL [:xtc4uall]]

(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).

Comment 18

[u52928]

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.