Last Comment Bug 757262 - Youtube keeps playing audio after closing
: Youtube keeps playing audio after closing
Status: RESOLVED FIXED
[qa-]
: qawanted, regression
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: 13 Branch
: x86 Mac OS X
: -- normal with 3 votes (vote)
: mozilla15
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
: Benjamin Smedberg [:bsmedberg]
Mentors:
Depends on: 760074 760883 769146
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-21 16:05 PDT by [:Cww]
Modified: 2015-11-16 11:45 PST (History)
31 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed
fixed


Attachments
wallpaper fix (1.04 KB, patch)
2012-05-28 22:12 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
jaas: review+
akeybl: approval‑mozilla‑aurora+
akeybl: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description [:Cww] 2012-05-21 16:05:32 PDT
From Input:

Youtube audio still plays even after closing the tab/window.

http://input.mozilla.org/en-US/?q=youtube+sound&product=firefox&version=13.0&date_start=&date_end=&sentiment=sad
http://input.mozilla.org/en-US/?product=firefox&sentiment=sad&date_end=&date_start=&version=13.0&q=youtube+close

Seems to be cross platform.  I don't have data on what versions of Flash etc.

Possibly related to bug 756250
Comment 1 [:Cww] 2012-05-21 16:18:58 PDT
Ooops cloned a bug and forgot to update the summary.

Also this is Firefox 13 specific, I can't find anything along these lines in 12.
Comment 2 Marcia Knous [:marcia - use ni] 2012-05-21 16:58:27 PDT
I tested this on two different Macs running two different versions of Flash and so far no luck reproducing with either youtube.com or netflix.

Next step would be to try some older versions since I am trying the latest Adobe shipping version and the latest labs version.
Comment 3 Alex Keybl [:akeybl] 2012-05-22 10:40:26 PDT
Including roc, josh, and bsmedberg since between this bug, bug 756250, and the lack of related input on FF12, it looks like we have a regression in FF13.
Comment 4 Alex Keybl [:akeybl] 2012-05-22 10:40:51 PDT
(I'm hoping that we know of recent plugin changes that could have caused this, since we haven't yet been able to repro)
Comment 5 Benjamin Smedberg [:bsmedberg] 2012-05-22 11:11:31 PDT
Bug 90268 is the obvious culprit. Josh, is it possible that bfcache is keeping plugins "alive" after the page is navigated when formerly it wouldn't (because the frame tree is torn down)?
Comment 6 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-05-22 11:26:26 PDT
bfcache shouldn't be involved for closed tabs, right?

This could happen if we somehow fail to close tabs (given the way our animations work it's possible for the tab to be invisible despite the underlying <browser> not being destroyed). I'm not sure of anything that would have landed in the 13 timeframe that might have caused this, though. Might it be a conflict with extensions? Can we ask some of the affected people for an add-on list?
Comment 7 Marcia Knous [:marcia - use ni] 2012-05-22 11:43:45 PDT
More testing on Windows 7 with different flash versions - latest Adobe shipping version and Version: 10.3.183.18 - have not yet been able to reproduce. Many of the input comments mention using the back button, so I was doing that as well as closing youtube tabs.
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2012-05-22 12:36:41 PDT
bfcache doesn't tear down frames, but _does_ explicitly stop all objects.

Maybe we should make page teardown do the same if it doesn't already?
Comment 9 Josh Aas 2012-05-22 13:45:48 PDT
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> Bug 90268 is the obvious culprit. Josh, is it possible that bfcache is
> keeping plugins "alive" after the page is navigated when formerly it
> wouldn't (because the frame tree is torn down)?

I remember explicitly working on making sure bfcache worked correctly with bug 90268. 'PresShell::Freeze' calls 'FreezeElement', which stops plugins. At least, that is what's supposed to be happening.

nsPresShell.cpp:
7036 static void
7037 FreezeElement(nsIContent *aContent, void * /* unused */)
7038 {
7039   nsCOMPtr<nsIObjectLoadingContent> olc(do_QueryInterface(aContent));
7040   if (olc) {
7041     olc->StopPluginInstance();
7042   }
7043 }
Comment 10 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-22 15:44:25 PDT
Closing a page should result in an immediate call to nsObjectLoadingContent::NotifyOwnerDocumentActivityChanged, which should stop the plugin.

Are we 100% sure that the reporters are using Flash and not getting <video> with WebM?
Comment 11 [:Cww] 2012-05-22 18:04:10 PDT
Not sure at all, I don't have any way of contacting them to ask either. Is there a likely suspect that would only affect webm?
Comment 12 IU 2012-05-22 18:17:13 PDT
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #10)
> Closing a page should result in an immediate call to
> nsObjectLoadingContent::NotifyOwnerDocumentActivityChanged, which should
> stop the plugin.
> 
> Are we 100% sure that the reporters are using Flash and not getting <video>
> with WebM?

Absolutely affects Flash -- 100% sure about that.  This bug is a regression from bug 90268, as it all began after that landed.

I experience this bug very frequently.

I find it is much easier to reproduce if you have flashblock installed.  I'm using the alpha build of flashblock available here: http://downloads.mozdev.org/flashblock/flashblock-1.5.unstable.xpi

PLEASE NOTE: If you're using that build of flashblock to test the issue on youtube, you MUST disable media.webm.enabled; otherwise, you will experience the following bug: https://www.mozdev.org/bugs/show_bug.cgi?id=24808

If I am able to come up with an STR, I will post it.
Comment 13 IU 2012-05-22 22:06:19 PDT
Here's some additional information on how I normally experience this bug.  If slightly different than how the reporter experiences it, it may still help identify the root cause:

Say I've just played a flash video (It could have been on youtube.com, cbsnews.com, or whatever) and I refresh the page to start the video over (Note: I don't have to have watched the video to the end) the video plays, but audio from a background instance of the same video also plays (about 1 second delayed).  It will not do this indefinitely.  It will usually continue this way for about 10 to 20 seconds then quit, leaving the foreground video and audio to continue.

For me, one way this happens is if I go back to the page where I was previously watching a view -- whether by reloading the page or undoing closed tab. It can also happen when moving from one video to another.

So, it seems to restart the prior instance, play it for a while then maybe detect it's no longer in the foreground and then kill it.
Comment 14 SpeciesX 2012-05-23 02:39:59 PDT
(In reply to IU from comment #12)
> Absolutely affects Flash -- 100% sure about that.  This bug is a regression
> from bug 90268, as it all began after that landed.
> 
> I experience this bug very frequently.

Not for me, i had this behavior the first time last week and only 2 or 3 times in 2 days.
Comment 15 Matthew Turnbull [Bluefang] 2012-05-23 12:56:43 PDT
I also have been seeing this for some time, and I do believe it is related to Bug 90268.

Unfortunately, I made the bad assumption that since this was happening on Youtube, a lot of people would experience it and it would have been reported quickly, so I didn't think to check Bugzilla. So shame on me :(

When I experience this, it's usually from navigating within a tab, not closing/opening tabs. For example:

1. Go to a channel.
2. View a video.
3. Navigate 'back' to get back to the channel.
4. View a different video.
5. New video plays and the audio from the previous video can be heard.

(alternatively, replace 3 & 4 with just selecting a related video)

This is definitely a plugin issue, because killing the plugin-container stops both the new and old video from playing.

Some other observations:

* If you navigate between videos quickly enough, you can get 3+ simultaneous audio tracks.

* When there is a video playing in the background, it doesn't necessarily play through the whole video. It often stops on its own after 30 - 60 seconds (I haven't timed it and I don't know if this time period is consistent across events).

* This doesn't always/predictably happen. Sometimes it happens on the second video I view after killing the plugin-container. Sometimes I can get through significantly more videos before it reappears.

Right now I have click-to-play enabled (awesome feature by the way), and I do still experience this. Next time it happens, I'll try and pay attention to whether this happens on page load, plugin load, or video play.

Implementation question:

Before the plugins-in-content landed, were browser-side plugin instances destroyed when navigating away from a page?

If so, maybe the 'simple' solution would be to explicitly destroy plugin instances when navigating away from a page. I'm guessing what's happening is that since the plugin instance is in the content, that it is being kept alive as long as the content is. That doesn't inherently sound like a problem to me, but it seems like these 'persisted' instances are somehow getting confused with the instances on the active page.
Comment 16 Josh Aas 2012-05-23 13:11:41 PDT
Can anyone who can reproduce this verify that they are *not* using flashblock when it happens? I wouldn't be surprised if flashblock was the cause.
Comment 17 IU 2012-05-23 13:26:46 PDT
(In reply to Josh Aas (Mozilla Corporation) from comment #16)
> Can anyone who can reproduce this verify that they are *not* using
> flashblock when it happens? I wouldn't be surprised if flashblock was the
> cause.

This IS NOT a flashblock issue.  You don't need flashblock or any other extension to reproduce it.  I merely suggested it because I find it easier to reproduce the issue when I have it.

The bug is in Firefox itself.
Comment 18 Alex Keybl [:akeybl] 2012-05-24 15:34:19 PDT
Given the leads in comments 13 and 15, adding qawanted to try to help find STR.
Comment 19 Alex Keybl [:akeybl] 2012-05-24 15:34:45 PDT
If there's anything QA can look for if they are able to repro, please let us know (logs, etc).
Comment 20 Jorge Villalobos [:jorgev] 2012-05-24 17:26:51 PDT
FWIW, I think this has happened to me a couple of times while looking at clips on http://www.thedailyshow.com/ and/or http://www.colbertnation.com. IIRC, one scenario where this happened was something like this:

1) Watch a clip.
2) Click on the link to the next clip.
3) Page isn't loading, so stop and reload.

After reloading successfully, I would see the second video and hear audio from the previous one.

I don't have Flashblock installed, but I do have NoScript, which can do a similar thing. Those sites are on the whitelist, so no additional action is necessary for the videos to play.

I tried to reproduce this a couple of times but wasn't able to.
Comment 21 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-24 18:01:14 PDT
It's vaguely possible this is related to bug 719117, which shows a way that a plugin could rise from the dead while a page is going into bfcache.
Comment 22 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-24 18:01:53 PDT
Maybe Alice can figure out steps to reproduce.
Comment 23 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-24 18:03:00 PDT
When people experience this bug, do they hear audio that carries on from where the plugin was playing before, or does the audio restart from the beginning again?
Comment 24 IU 2012-05-24 19:26:52 PDT
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #23)
> When people experience this bug, do they hear audio that carries on from
> where the plugin was playing before, or does the audio restart from the
> beginning again?

For me, it always starts at the beginning -- just as if the prior video was started afresh.
Comment 25 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-24 19:35:46 PDT
It could possibly be 719117 then.
Comment 26 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-24 19:38:19 PDT
Another question: does the prior video always start replaying immediately (or soon) after leaving its page? Or is more interaction required to trigger the prior video to start playing?
Comment 27 IU 2012-05-24 20:51:53 PDT
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #26)
> Another question: does the prior video always start replaying immediately
> (or soon) after leaving its page? Or is more interaction required to trigger
> the prior video to start playing?

It depends.  In the case of a page reload it starts as soon as the page is loaded but is always about a second off from any video loaded in the immediate page.  For instance, say I was watching a video and reloaded the page to restart the video, the audio for the phantom stream will be about 1 sec out of sync, which is of course why it's noticeable.  The same with when a new page with a new video is loaded: the phantom audio stream from the old video will lead that of the immediate video by about 1 sec.

I should, however, note that in the case of a tab being closed and audio continuing, that one does not restart from the beginning but continues to play for several seconds before finally dying out.  I forgot about this when providing my earlier response.
Comment 28 Norbert Pozar 2012-05-24 23:01:26 PDT
I can confirm the bug on Aurora 14.0a2 (2012-05-24) with Flash 11.1.102.55.

It is quite unpredictable, but it happens often enough to be annoying:

1) watch a youtube video (or nasatv or whatever)
2) navigate away from the page
3) the video starts playing from the beginning in the background, as if the plugin was restarted
Comment 29 paulus 2012-05-25 07:25:11 PDT
Bug 754574
In ff12 when minimized spoiler flashclip stops and the browser clears the cache.

Spoiler is deployed, the video is:
paul @ ubuntu: ~$ lsof-n | grep /tmp/Flash
plugin-co 3621 paul 16w REG 8,2 128 908 854 132 008 /tmp/FlashXXIS0DNA (deleted)

Spoiler collapsed, the video at a pace not:
paul @ ubuntu: ~$ lsof-n | grep /tmp/Flash
paul @ ubuntu: ~$

In all other versions of the browser (beta, aurora, nightly) is only a folding spoiler (regress). Video plays on and you have to manually press the stop/pause before folding spoiler and the memory are all videos that terribly uses RAM.

flashplugin-installer_11.2.202.233ubuntu2_amd64.deb
http://zerx.ru
http://www.animejapan.ru
Comment 30 Mats Palmgren (:mats) 2012-05-25 12:48:57 PDT
Please test the Try builds (with the fix for bug 719117) at:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla.com-174800d84600/
Comment 31 Hal Wine [:hwine] (out till Dec 12) (use NI) 2012-05-25 14:42:21 PDT
I can get a consistent repro of this as follows (osx 10.7.4, Aurora 14.0a2 5/19):
 - go to Addons page
 - click "Get Addons"
 - watch the video
 - click back button: both audio & actions continue (can tell via persona updates in frame)
Comment 32 Marcia Knous [:marcia - use ni] 2012-05-25 15:00:33 PDT
The back button on the addons page is a bit different than other pages, so what you are seeing is probably expected.

(In reply to Hal Wine [:hwine] from comment #31)
> I can get a consistent repro of this as follows (osx 10.7.4, Aurora 14.0a2
> 5/19):
>  - go to Addons page
>  - click "Get Addons"
>  - watch the video
>  - click back button: both audio & actions continue (can tell via persona
> updates in frame)
Comment 33 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-25 17:04:17 PDT
(In reply to IU from comment #27)
> I should, however, note that in the case of a tab being closed and audio
> continuing, that one does not restart from the beginning but continues to
> play for several seconds before finally dying out.  I forgot about this when
> providing my earlier response.

That suggests this is not related to bug 719117.
Comment 34 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-25 17:05:09 PDT
But definitely try the try builds in comment #30!
Comment 35 IU 2012-05-25 20:30:12 PDT
So far, in my testing using the try build, I have not yet encountered the issue.  I'll continue testing tomorrow and provide an update hopefully before Sunday.
Comment 36 IU 2012-05-26 13:52:22 PDT
Definitely NOT fixed by bug 719117.

I tested today using an hourly (cset cd62c4b8f500) with the bug 719117 fix.

These roughly were my steps, though there's no guarantee that following this will necessarily help with reproducing the issue:

I had more than one browser window open -- each with more than one tab.

I had ABC News 20/20 page (http://abcnews.go.com/2020) loaded as one of the tabs in one window.  I started the first video "How Agents Foiled Casino Scam," but paused it about 5 seconds in.  Leaving it paused...

In one of my other browser windows, I load the Discovery Channel (Canada) video player and watched (a typically hour-long episode posted as about 44 minutes of video in 6 parts).  When finished, I closed the tab then dragged the tab loaded with ABC News 20/20 page (http://abcnews.go.com/2020) to the window where I previously had the Discovery Channel tab.

I un-paused the 20/20 video allowing it to play through and automatically advance to the second video when done; however, I allowed the second video to play for only about 20 seconds before I reloaded the page.  On reload, no video on the page auto started (this is normal) yet, audio from the previous video played (from the start) for about 4 seconds.
Comment 37 Mats Palmgren (:mats) 2012-05-26 14:08:11 PDT
Thanks for testing.  On which OS are you testing?  and which version of Flash?
Comment 38 IU 2012-05-26 14:17:39 PDT
Windows XP SP3 fully patched + Flash Player 11.2.202.235
Comment 39 IU 2012-05-26 16:39:50 PDT
Way back when IPC plugins was under development, there was a command line based way to launch Firefox and log messages from plugin interaction.  Does this capability still exist?  If not, is there something (not complicated) that I would be able to run that could capture what's happening with plugins in the background?
Comment 40 IU 2012-05-27 07:12:17 PDT
Additional observation that might be helpful:

Again, I have multiple windows open (though this detail might be irrelevant to the issue).

I finished watching a 43-minute youtube video and left the tab and window untouched after the video finished.  I then was doing other things and browsing using another browser window.  Close to an hour must have elapsed and I then went back to the tab where I had been watching the video.  I entered a non-video site URL into the URL bar (I don't remember what site) and when the new page loaded, audio from the youtube video played for about 5 to 7 seconds.
Comment 41 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-28 22:12:59 PDT
Created attachment 627853 [details] [diff] [review]
wallpaper fix

I think we should try this.
Comment 42 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-28 22:19:33 PDT
Tryserver push:
https://tbpl.mozilla.org/?tree=Try&rev=6cc1814784d8

Builds to try out:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/rocallahan@mozilla.com-6cc1814784d8

I would love to know if this helps...
Comment 43 Josh Aas 2012-05-29 05:09:35 PDT
Comment on attachment 627853 [details] [diff] [review]
wallpaper fix

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

Worth a shot! Thanks.

::: content/base/src/nsObjectLoadingContent.cpp
@@ +661,1 @@
>    doc->FlushPendingNotifications(Flush_Layout);

Can active state change during the call to FlushPendingNotifications? Seems like you put the check before that call quite explicitly, just wondering what your logic is.
Comment 44 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-29 05:14:04 PDT
(In reply to Josh Aas (Mozilla Corporation) from comment #43)
> Can active state change during the call to FlushPendingNotifications? Seems
> like you put the check before that call quite explicitly, just wondering
> what your logic is.

I don't think it can. That was not deliberate.
Comment 45 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-29 06:15:06 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/5a1073bd1865
Comment 46 IU 2012-05-29 08:50:34 PDT
Probably won't be able to provide feedback before Thursday or Friday.
Comment 47 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-05-29 12:05:21 PDT
(In reply to IU from comment #46)
> Probably won't be able to provide feedback before Thursday or Friday.

Thanks IU, any chance you can try to reduce your testcase to something that doesn't require a couple hours of waiting and testing?

Note: I asked our Romanian testers to try to reproduce this issue using IU's testcase but they failed to reproduce it in Windows and Linux.
Comment 48 IU 2012-05-29 14:37:45 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #47)
> Thanks IU, any chance you can try to reduce your testcase to something that
> doesn't require a couple hours of waiting and testing?

Unfortunately, reproducibility is random.  Sometimes it's reproducible within minutes of using the browser; sometimes it takes a while.  Also, sometimes it's reproducible back-to-back; other times it's not.

This is why having the ability to log what Firefox is doing, with regards to plugins, would be helpful.
Comment 49 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-05-29 15:09:57 PDT
IU, not sure if it will help, but there are debug builds for our last Beta here:
ftp://ftp.mozilla.org/pub/firefox/nightly/2012-05-22-mozilla-beta-debug/
Comment 50 Brian Hourigan [:digi] 2012-05-29 16:02:56 PDT
I noticed this behavior at home the other day. I was watching a video on YouTube, I hit the pause button, but the audio continued. After I figured out where it was coming from I just closed the tab and the audio stopped.
Comment 51 Tom Lowenthal 2012-05-29 16:20:55 PDT
Similar experience with YouTube and other similar flash video sites. Happens most often when I open many videos in different tabs -- though that may just be because that's when I most frequently open videos. For me, audio persists even after closing tab, and continue until the end of the phantom video. Unable to reliably repro (even with same video & tab combos), but have not noticed problem since FF14.
Comment 52 IU 2012-05-29 17:33:47 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #49)
> IU, not sure if it will help, but there are debug builds for our last Beta
> here:
> ftp://ftp.mozilla.org/pub/firefox/nightly/2012-05-22-mozilla-beta-debug/

Unfortunately, the prebuilt debug builds require additional setup that I have never succeeded in figuring out.  Searches for instructions have always been fruitless, with all instruction I have ever found being focused on compilation from scratch -- something I am not setup to do.  For those reasons, I cannot use the debug builds.
Comment 53 Ed Morley [:emorley] 2012-05-30 08:18:28 PDT
https://hg.mozilla.org/mozilla-central/rev/5a1073bd1865
Comment 54 Benjamin Smedberg [:bsmedberg] 2012-05-30 13:33:42 PDT
FWIW, I hit this new error while frequently reloading a Java <applet> in another bug. The stack is this:

 	xul.dll!RealBreak()  Line 416	C++
 	xul.dll!Break(aMsg=0x0040ab70)  Line 515	C++
 	xul.dll!NS_DebugBreak_P(aSeverity=0x00000001, aStr=0x57f71b98, aExpr=0x57f71b90, aFile=0x57f71b20, aLine=0x00000292)  Line 374	C++
>	xul.dll!nsObjectLoadingContent::InstantiatePluginInstance(aMimeType=0x0cc28530, aURI=0x0cc285f0)  Line 658	C++
 	xul.dll!nsObjectLoadingContent::SyncStartPluginInstance()  Line 2107	C++
 	xul.dll!nsHTMLPluginObjElementSH::GetPluginInstanceIfSafe(wrapper=0x07fb2460, obj=0x07b9b380, _result=0x0040b154)  Line 9590	C++
 	xul.dll!nsHTMLPluginObjElementSH::SetupProtoChain(wrapper=0x07fb2460, cx=0x0878d778, obj=0x07b9b380)  Line 9655	C++
 	xul.dll!nsHTMLPluginObjElementSH::PostCreate(wrapper=0x07fb2460, cx=0x0878d778, obj=0x07b9b380)  Line 9755	C++
 	xul.dll!FinishCreate(ccx={...}, Scope=0x0d39ebc0, Interface=0x0a752048, cache=0x0a5ea944, inWrapper=0x07fb2460, resultWrapper=0x0040b664)  Line 716	C++
 	xul.dll!XPCWrappedNative::GetNewOrUsed(ccx={...}, helper={...}, Scope=0x0d39ebc0, Interface=0x0a752048, resultWrapper=0x0040b664)  Line 662	C++
 	xul.dll!XPCWrappedNative::GetNewOrUsed(ccx={...}, helper={...}, Scope=0x087b2860, Interface=0x0a752048, resultWrapper=0x0040b664)  Line 549	C++
 	xul.dll!XPCConvert::NativeInterface2JSObject(lccx={...}, d=0x0040ba5c, dest=0x00000000, aHelper={...}, iid=0x0040ba30, Interface=0x00000000, allowNativeWrapper=true, pErr=0x0040ba04)  Line 957	C++
 	xul.dll!XPCConvert::NativeData2JS(lccx={...}, d=0x0040ba5c, s=0x0040bab8, type={...}, iid=0x0040ba30, pErr=0x0040ba04)  Line 324	C++
 	xul.dll!XPCConvert::NativeData2JS(ccx={...}, d=0x0040ba5c, s=0x0040bab8, type={...}, iid=0x0040ba30, pErr=0x0040ba04)  Line 3213	C++
 	xul.dll!CallMethodHelper::GatherAndConvertResults()  Line 2593	C++
 	xul.dll!CallMethodHelper::Call()  Line 2404	C++
 	xul.dll!XPCWrappedNative::CallMethod(ccx={...}, mode=CALL_GETTER)  Line 2356	C++
 	xul.dll!XPCWrappedNative::GetAttribute(ccx={...})  Line 2717	C++
 	xul.dll!XPC_WN_GetterSetter(cx=0x0878d778, argc=0x00000000, vp=0x072600c0)  Line 1548	C++
 	mozjs.dll!js::CallJSNative(cx=0x0878d778, native=0x55baac49, args={...})  Line 395	C++
 	mozjs.dll!js::InvokeKernel(cx=0x0878d778, args={...}, construct=NO_CONSTRUCT)  Line 310	C++
 	mozjs.dll!js::Invoke(cx=0x0878d778, args={...}, construct=NO_CONSTRUCT)  Line 125	C++
 	mozjs.dll!js::Invoke(cx=0x0878d778, thisv={...}, fval={...}, argc=0x00000000, argv=0x00000000, rval=0x0040c5fc)  Line 358	C++
 	mozjs.dll!js::InvokeGetterOrSetter(cx=0x0878d778, obj=0x08ca37e0, fval={...}, argc=0x00000000, argv=0x00000000, rval=0x0040c5fc)  Line 432	C++
 	mozjs.dll!js::Shape::get(cx=0x0878d778, receiver={...}, obj=0x08ca37e0, pobj=0x08ca37a0, vp=0x0040c5fc)  Line 274	C++
 	mozjs.dll!js_NativeGetInline(cx=0x0878d778, receiver=0x08ca37e0, obj=0x08ca37e0, pobj=0x08ca37a0, shape=0x0b8ee598, getHow=0x00000001, vp=0x0040c5fc)  Line 4938	C++
 	mozjs.dll!js_GetPropertyHelperInline(cx=0x0878d778, obj={...}, receiver={...}, id_={...}, getHow=0x00000001, vp=0x0040c5fc)  Line 5087	C++
 	mozjs.dll!js::GetPropertyHelper(cx=0x0878d778, obj={...}, id={...}, getHow=0x00000001, vp=0x0040c5fc)  Line 5096	C++
 	mozjs.dll!js::GetPropertyOperation(cx=0x0878d778, pc=0x0c8e4b73, lval={...}, vp=0x0040c5fc)  Line 230	C++
 	mozjs.dll!js::Interpret(cx=0x0878d778, entryFrame=0x07260068, interpMode=JSINTERP_NORMAL)  Line 2407	C++
 	mozjs.dll!js::RunScript(cx=0x0878d778, script=0x0d84a028, fp=0x07260068)  Line 266	C++
 	mozjs.dll!js::InvokeKernel(cx=0x0878d778, args={...}, construct=NO_CONSTRUCT)  Line 326	C++
 	mozjs.dll!js::Invoke(cx=0x0878d778, args={...}, construct=NO_CONSTRUCT)  Line 125	C++
 	mozjs.dll!js::Invoke(cx=0x0878d778, thisv={...}, fval={...}, argc=0x00000001, argv=0x0040cae4, rval=0x0040cc2c)  Line 358	C++
 	mozjs.dll!JS_CallFunctionValue(cx=0x0878d778, obj=0x08ca3aa0, fval={...}, argc=0x00000001, argv=0x0040cae4, rval=0x0040cc2c)  Line 5496	C++
 	xul.dll!nsJSContext::CallEventHandler(aTarget=0x09ff98e8, aScope=0x08ca2040, aHandler=0x0d84c080, aargv=0x0685d4b8, arv=0x0040ce58)  Line 1898	C++
 	xul.dll!nsJSEventListener::HandleEvent(aEvent=0x07f7cfc0)  Line 191	C++
 	xul.dll!nsEventListenerManager::HandleEventSubType(aListenerStruct=0x086f17b0, aListener=0x09ff9a08, aDOMEvent=0x07f7cfc0, aCurrentTarget=0x09ff98e8, aPhaseFlags=0x00000006, aPusher=0x0040d034)  Line 809	C++
 	xul.dll!nsEventListenerManager::HandleEventInternal(aPresContext=0x088b7700, aEvent=0x0040d13c, aDOMEvent=0x0040d024, aCurrentTarget=0x09ff98e8, aFlags=0x00000006, aEventStatus=0x0040d028, aPusher=0x0040d034)  Line 868	C++
 	xul.dll!nsEventListenerManager::HandleEvent(aPresContext=0x088b7700, aEvent=0x0040d13c, aDOMEvent=0x0040d024, aCurrentTarget=0x09ff98e8, aFlags=0x00000006, aEventStatus=0x0040d028, aPusher=0x0040d034)  Line 138	C++
 	xul.dll!nsEventTargetChainItem::HandleEvent(aVisitor={...}, aFlags=0x00000006, aMayHaveNewListenerManagers=false, aPusher=0x0040d034)  Line 186	C++
 	xul.dll!nsEventTargetChainItem::HandleEventTargetChain(aVisitor={...}, aFlags=0x00000006, aCallback=0x00000000, aMayHaveNewListenerManagers=false, aPusher=0x0040d034)  Line 319	C++
 	xul.dll!nsEventDispatcher::Dispatch(aTarget=0x09ff98e8, aPresContext=0x088b7700, aEvent=0x0040d13c, aDOMEvent=0x00000000, aEventStatus=0x0040d138, aCallback=0x00000000, aTargets=0x00000000)  Line 643	C++
 	xul.dll!nsXULPopupManager::FirePopupShowingEvent(aPopup=0x09ff98e8, aIsContextMenu=false, aSelectFirstItem=false)  Line 1156	C++
 	xul.dll!nsXULPopupManager::ShowTooltipAtScreen(aPopup=0x09ff98e8, aTriggerContent=0x0a5ea940, aXPos=0x00000419, aYPos=0x00000108)  Line 635	C++
 	xul.dll!nsXULTooltipListener::LaunchTooltip()  Line 516	C++
 	xul.dll!nsXULTooltipListener::ShowTooltip()  Line 410	C++
 	xul.dll!nsXULTooltipListener::sTooltipCallback(aTimer=0x0a4f94b8, aListener=0x0a3b1e50)  Line 708	C++
 	xul.dll!nsTimerImpl::Fire()  Line 473	C++
 	xul.dll!nsTimerEvent::Run()  Line 558	C++
 	xul.dll!nsThread::ProcessNextEvent(mayWait=true, result=0x0040d48f)  Line 624	C++
 	xul.dll!NS_ProcessNextEvent_P(thread=0x004233a8, mayWait=true)  Line 213	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(aDelegate=0x00421330)  Line 113	C++
 	xul.dll!MessageLoop::RunInternal()  Line 209	C++
 	xul.dll!MessageLoop::RunHandler()  Line 202	C++
 	xul.dll!MessageLoop::Run()  Line 176	C++
 	xul.dll!nsBaseAppShell::Run()  Line 165	C++
 	xul.dll!nsAppShell::Run()  Line 232	C++
 	xul.dll!nsAppStartup::Run()  Line 256	C++
 	xul.dll!XREMain::XRE_mainRun()  Line 3786	C++
Comment 55 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-30 19:57:05 PDT
Got a testcase? I tried reloading
http://java.sun.com/applets/jdk/1.4/demo/applets/Fractal/example1.html
many times and didn't get an assertion.
Comment 56 IU 2012-05-30 20:04:13 PDT
So far as original subject of this patch is concerned, I believe it is indeed safe to consider it fixed.  I am no longer able to reproduce using any build with the patch included.  Thanks.
Comment 57 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-05-30 20:48:22 PDT
Comment on attachment 627853 [details] [diff] [review]
wallpaper fix

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

Impact: rather serious user-facing regression.

Risk: The main regression risk is that under some conditions involving navigating through cached pages, plugins might fail to instantiate properly. No reports of that yet.
Comment 58 Alex Keybl [:akeybl] 2012-05-31 10:45:13 PDT
Comment on attachment 627853 [details] [diff] [review]
wallpaper fix

[Triage Comment]
This was our top remaining tracked issue, and is a regression in FF13. Approved for Aurora 14 and Beta 13. We're going to spin another Beta with this fix asap.
Comment 60 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-01 11:50:07 PDT
Builds are now available if people want to test:
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-aurora/
ftp://ftp.mozilla.org/pub/firefox/releases/13.0b7/

Thanks
Comment 61 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-06-04 14:39:17 PDT
Actually, I'm changing my mind in terms of tracking. Since we don't really have a reproducible case, QA will be unable to accurately verify this fix. As a result, changing whiteboard tag to [qa-]. If we end up discovering a reproducible case, please set tag to [qa+] so we can test it.

Otherwise, tracking with qawanted keyword to evaluate user feedback.
Comment 62 David 2012-08-14 11:27:07 PDT
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #61)
> Actually, I'm changing my mind in terms of tracking. Since we don't really
> have a reproducible case, QA will be unable to accurately verify this fix.
> As a result, changing whiteboard tag to [qa-]. If we end up discovering a
> reproducible case, please set tag to [qa+] so we can test it.
> 
> Otherwise, tracking with qawanted keyword to evaluate user feedback.


Firefox
Comment 63 Notlost 2012-08-14 12:53:57 PDT
According to recent activity on the mailing list, this issue seems to still occur in the latest nightly (17.0a1 8-13-12). I personally cannot reproduce it, but there were 3 confirmations on the list, so I'd suggest reopening this.
Comment 64 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-08-14 13:08:13 PDT
We need more information to go on before we can reopen this bug, as requested in the mailing list. Things like Flash version, URLs, steps to reproduce, hardware/OS information etc. Until someone can comment in this bug with specifics, we won't be able to reopen this bug.
Comment 65 IU 2012-08-14 16:38:36 PDT
(In reply to Notlost from comment #63)
> According to recent activity on the mailing list, this issue seems to still
> occur in the latest nightly (17.0a1 8-13-12)...

What you're referring to is actually a new regression resulting from the landing of bug 745030.  The issue is referenced in bug 781482 and is supposed to be fixed by bug 767635.
Comment 66 dean 2014-01-21 12:28:05 PST
currently getting this bug on firefox on windows 7 64bit latest flash player
Comment 67 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2014-01-21 13:40:31 PST
(In reply to dean from comment #66)
> currently getting this bug on firefox on windows 7 64bit latest flash player

This issue was resolved over a year ago. Please file a new bug report and give us more details about your system so we can try to replicate the problem.
Comment 68 Chris 2014-03-18 18:28:29 PDT
umm you mean you thought you resolved it?

I have had the issue for about half a year or so maybe more, I didnt report it because I thought firefox wouldnt keep such a silly bug for that long and forgot about it as been using youtube centre for a while but wow was I wrong.

So

using win 7 64 bit SP1
I can duplicate bug on 6 rigs.
all my firends who use windows get bug
cannot duplicate it on linux rigs


Using forefix esr-v24
16 gig ram
cpu i5 750
nod 32 av
adblock plus loaded
noscript loaded

I can confirm youtube centre extension stops the bug from occuring, sadly that plugin has very severe memleaks and also slows down youtube, but it does 100% stop it occuring somehow.

I am not using flashblock.

devs still going to rpetend its fixed?  I guess this bug will exist for years/forever?
Comment 69 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2014-03-18 20:17:11 PDT
(In reply to Chris from comment #68)
> devs still going to rpetend its fixed?  I guess this bug will exist for
> years/forever?

Please file a new bug report with your information so it can be investigated.
Comment 70 Chris 2014-03-19 07:43:33 PDT
I got better idea, I will contact youtube centre developer to ask how he fixed the problem and then post the fix here.
Comment 71 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2014-03-19 14:09:04 PDT
(In reply to Chris from comment #70)
> I got better idea, I will contact youtube centre developer to ask how he
> fixed the problem and then post the fix here.

Even still, you should report a new bug to communicate that information. There's nothing more to be done in *this* bug report. Thank you.
Comment 72 Chris 2014-03-20 20:40:55 PDT Comment hidden (obsolete)
Comment 73 Chris 2014-03-20 20:41:34 PDT
so to confirm you want the same bug reported twice?
Comment 74 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2014-03-26 10:43:44 PDT
(In reply to Chris from comment #73)
> so to confirm you want the same bug reported twice?

I want your particular use case, steps to reproduce, and configuration to be reported separately, yes. We will not be reopening this bug report to address your issue. If you want it investigated you need to file a new report. I'm sorry if that's inconvenient but that's how this works.
Comment 75 Chris 2014-04-17 21:51:37 PDT
Ok so steps to reproduce.

load firsfox in default config, no plugins windows 7 64bit sp1. latest version of 32bit flash. can repeat clean profile.

view various youtube videos, refresh same videos etc.

memory usage goes up out of control eventually will crash, also the youtube keeps playing bug will occur.

If load addon youtube center the bug dissapears, developer said he fixed it by force closing the plugin container exe when exiting video page.

I then tested with plugin container disabled, this was hard to do as seems its been made harder to do now but eventually figured out how to disable it.

Can confirm with it disabled and no youtube center addon bug doesnt occur.  Also memory recovers when closing tabs (memory doesnt recover if either you tube center addon loaded or plugin container used).  This is on clean profile, with no addons.

So it seems on my rig plugin container triggers the problem.

Also when bug does occur force killing plugin container stops the audio.
Comment 76 Benjamin Smedberg [:bsmedberg] 2014-04-19 13:43:24 PDT
Chris, could you please file this as a new bug (Product: Core Component: Plug-Ins). Your report has some of the same symptoms as the thing was which has already been fixed, but appears to have a very different cause. I do very much want to dig deeper into this, since we've had people reporting more problems on youtube recently and we need to fix it. Please cc me on the bug you file.
Comment 77 daniel.2345 2014-06-21 01:00:19 PDT
The bug was fixed in Firefox 29, but present in Firefox 30 once I updated my Firefox
Comment 78 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2014-06-23 10:45:14 PDT
(In reply to daniel.2345 from comment #77)
> The bug was fixed in Firefox 29, but present in Firefox 30 once I updated my
> Firefox

As mentioned in previous comments, please file a new bug with your steps to reproduce.
Comment 79 adelpozoman 2015-11-15 14:01:04 PST
Notice that it is still alive in Ubuntu 10.04, adobe flash using shocwave flash plugin(r11) at palemoon browser(version 25). My computer cant handle anything better nowadays...
Comment 80 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2015-11-16 11:45:33 PST
(In reply to adelpozoman from comment #79)
> Notice that it is still alive in Ubuntu 10.04, adobe flash using shocwave
> flash plugin(r11) at palemoon browser(version 25). My computer cant handle
> anything better nowadays...

I'm sorry but we do not support Ubuntu 10.04.

Note You need to log in before you can comment on or make changes to this bug.