Closed Bug 757262 Opened 12 years ago Closed 12 years ago

Youtube keeps playing audio after closing

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
13 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox13+ fixed, firefox14 fixed)

Status:
RESOLVED FIXED
Milestone:
mozilla15
Tracking Flags:
Tracking Status
firefox13 + fixed
firefox14 --- fixed

People

(Reporter: cww, Assigned: roc)

References

Details

(Keywords: qawanted, regression, Whiteboard: [qa-])

Attachments

(1 file)

wallpaper fix
1.04 KB, patch
jaas
: review+
akeybl
: approval-mozilla-aurora+
akeybl
: approval-mozilla-beta+
Details | Diff | Splinter Review 
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
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.
Summary: Netflix keeps playing after closing → Youtube keeps playing audio after closing
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.
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.
See Also: → 756250
(I'm hoping that we know of recent plugin changes that could have caused this, since we haven't yet been able to repro)
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)?
Component: Flash (Adobe) → Plug-ins
Product: Plugins → Core
QA Contact: adobe-flash → plugins
Version: 13.x → unspecified
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?
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.
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?
(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 }
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?
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?
(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.
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.
(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.
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.
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.
(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.
Given the leads in comments 13 and 15, adding qawanted to try to help find STR.
Keywords: qawanted
If there's anything QA can look for if they are able to repro, please let us know (logs, etc).
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.
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.
Maybe Alice can figure out steps to reproduce.
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?
(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.
It could possibly be 719117 then.
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?
(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.
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
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
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)
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)
Depends on: 719117
(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.
But definitely try the try builds in comment #30!
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.
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.
Thanks for testing.  On which OS are you testing?  and which version of Flash?
No longer depends on: 719117
Windows XP SP3 fully patched + Flash Player 11.2.202.235
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?
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.
Attached patch wallpaper fix — — Splinter Review 
I think we should try this.
Attachment #627853 - Flags: review?(joshmoz)
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.
Attachment #627853 - Flags: review?(joshmoz) → review+
(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.
Probably won't be able to provide feedback before Thursday or Friday.
(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.
(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.
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/
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.
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.
(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.
https://hg.mozilla.org/mozilla-central/rev/5a1073bd1865
Assignee: nobody → roc
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
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++
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.
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 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.
Attachment #627853 - Flags: approval-mozilla-beta?
Attachment #627853 - Flags: approval-mozilla-aurora?
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.
Attachment #627853 - Flags: approval-mozilla-beta?
Attachment #627853 - Flags: approval-mozilla-beta+
Attachment #627853 - Flags: approval-mozilla-aurora?
Attachment #627853 - Flags: approval-mozilla-aurora+
Keywords: qawanted
Whiteboard: [qa+]
Depends on: 760883
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.
Keywords: qawanted
Whiteboard: [qa+] → [qa-]
Depends on: 769146
Keywords: regression
Version: unspecified → 13 Branch
(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
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.
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.
(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.
currently getting this bug on firefox on windows 7 64bit latest flash player
(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.
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?
(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.
I got better idea, I will contact youtube centre developer to ask how he fixed the problem and then post the fix here.
(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.
so to confirm you want the same bug reported twice?
(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.
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.
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.
The bug was fixed in Firefox 29, but present in Firefox 30 once I updated my Firefox
(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.
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...
(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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: