Last Comment Bug 438830 - Plugins can be instantiated, killed, then reinstantiated when a page loads
: Plugins can be instantiated, killed, then reinstantiated when a page loads
Status: RESOLVED FIXED
[needs 445520 fixed]
: fixed1.9.1, verified1.9.0.6
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
: -- normal with 47 votes (vote)
: ---
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
:
: Benjamin Smedberg [:bsmedberg]
Mentors:
: 439146 441424 442666 445599 465374 (view as bug list)
Depends on: 445520 474022
Blocks: abp
  Show dependency treegraph
 
Reported: 2008-06-12 05:40 PDT by Jonathan Watt [:jwatt]
Modified: 2012-05-02 03:50 PDT (History)
59 users (show)
jst: blocking1.9.1+
mbeltzner: blocking1.9.0.1-
dveditz: blocking1.9.0.6+
jst: wanted1.9.0.x+
samuel.sidler+old: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
double-instantiate.patch (1.24 KB, patch)
2008-06-18 17:23 PDT, Shane Caraveo
no flags Details | Diff | Splinter Review
Stop double instantiation even earlier. (2.54 KB, patch)
2008-06-26 11:28 PDT, Johnny Stenback (:jst, jst@mozilla.com)
jonas: review+
jonas: superreview+
samuel.sidler+old: approval1.9.0.2-
dveditz: approval1.9.0.4-
dveditz: approval1.9.0.6+
Details | Diff | Splinter Review

Description Jonathan Watt [:jwatt] 2008-06-12 05:40:52 PDT
When a page embeds content that is handled by a plugin, it is possible for the plugin to be instantiated, destroyed, then instantiated again, all during the page load. This can mean that scripted commands to the plugin during the page load can be wiped out without the script noticing.

This problem can occur if script in the page accesses the plugin before the first reflow of the embedding element. This is because we synchronously instantiate the plugin if script tries to access it through the DOM before it has been instantiated. Then, regardless of whether the plugin has been instantiated or not, when the embedding element gets its first reflow, it posts an event to instantiate the plugin to the event loop. When this event is run, the "old" plugin instance is shut down and then a new instance is reinstantiated.
Comment 1 Jonathan Watt [:jwatt] 2008-06-12 05:49:18 PDT
To give slightly more technical detail, it's nsObjectLoadingContent::HasNewFrame that posts the nsAsyncInstantiateEvent to the event loop when the embedding element is reflowed (at least in the case when the embedding element is an <object>). HasNewFrame is currently only called from nsObjectFrame::DidReflow.
Comment 2 Shane Caraveo 2008-06-16 11:28:37 PDT
*** Bug 439146 has been marked as a duplicate of this bug. ***
Comment 3 Shane Caraveo 2008-06-16 11:30:12 PDT
I have a patch in bug 439146 that fixes this for us, just not sure if it's the right way to fix this issue.  It checks to see if the plugin instance exists, if if it does, prevents the second instantiation which causes the unload/reload.
Comment 4 Shane Caraveo 2008-06-17 08:52:43 PDT
Once the dust settles (fx 3 release) I'd like to get some feedback on the patch.
Comment 5 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-18 12:27:32 PDT
Shane, can you show a stack of how this double-instantiation happens? I.e. break in your patch where you return early due to an instance already existing in the frame. Also, pelase attach that patch to this bug as well, makes it easier to talk about...
Comment 6 Shane Caraveo 2008-06-18 17:19:21 PDT
Here's a traceback from placing a call to Debugger where I was returning if a plugin instance existed.

Breakpoint 1, 0x95c7d86d in Debugger ()
(gdb) bt
#0  0x95c7d86d in Debugger ()
#1  0x09e6b54b in nsObjectLoadingContent::Instantiate ()
#2  0x09e6b79e in nsAsyncInstantiateEvent::Run ()
#3  0x001bd6da in nsThread::ProcessNextEvent ()
#4  0x0017dcb7 in NS_ProcessPendingEvents_P ()
#5  0x007bbd22 in nsBaseAppShell::NativeEventCallback ()
#6  0x0078c99a in nsAppShell::ProcessGeckoEvents ()
#7  0x930a462e in CFRunLoopRunSpecific ()
#8  0x930a4d18 in CFRunLoopRunInMode ()
#9  0x961976a0 in RunCurrentEventLoopInMode ()
#10 0x961973f2 in ReceiveNextEventCommon ()
#11 0x9619732d in BlockUntilNextEventMatchingListInMode ()
#12 0x920ae7d9 in _DPSNextEvent ()
#13 0x920ae08e in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#14 0x920a70c5 in -[NSApplication run] ()
#15 0x0078bcfa in nsAppShell::Run ()
#16 0x005c8367 in nsAppStartup::Run ()
#17 0x0004ce15 in XRE_main ()
#18 0x00005c04 in main ()
Comment 7 Shane Caraveo 2008-06-18 17:23:41 PDT
Created attachment 325668 [details] [diff] [review]
double-instantiate.patch
Comment 8 Brian Polidoro 2008-06-23 18:25:28 PDT
See also bug 441424 which sounds like this problem too. 
Comment 9 Tristan Schmelcher 2008-06-26 10:59:39 PDT
Hi, I can confirm this bug and also that Shane's patch works. I actually independently made a near-identical patch and put it on bug 90268. :)

FYI, if you're a webpage developer then an easy workaround to get your page working with FF3 is to delay accessing any plugins until after your page has fully loaded. An easy way to do this is to schedule your plugin scripting code to run after all pending browser events using window.setTimeout with a timeout of zero.

Alternatively, if you are an NPAPI plugin developer and your plugin gets given a callback function by the webpage, then you get your plugin working with FF3 on broken webpages by invoking some callback that will cause the webpage to immediately access your plugin. When it accesses your plugin, that runs nsObjectLoadingContent::EnsureInstantiation, which cancels any pending nsAsyncInstantiateEvents, even when already instantiated. Hence if you invoke such a callback at just the right time then it will cancel the pending unload/reload. It's hard to get the timing right though.
Comment 10 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-26 11:28:49 PDT
Created attachment 326964 [details] [diff] [review]
Stop double instantiation even earlier.

This is based on Shane's earlier fix, but moves it even earlier in the process. The problem is that we end up in some cases instantiating the plugin from JS (due to JS content policy implementations or actions by the page etc), and then once the plugin frame is reflown, we don't notice that its plugin has already been instantiated so we re-instantiate (asynchronously). This patch makes us detect that the new frame already has a plugin in it, and doesn't even post the event to asynchronously instantiate the (already instantiated) plugin.

Bug 441424 has a good testcase for this problem, using an extension that contains a JS content policy implementation.

Shane, if you can test this patch as well (and Tristan too, if you have time to test yet another patch!), I'd really appreciate it.
Comment 11 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-26 11:30:24 PDT
*** Bug 441424 has been marked as a duplicate of this bug. ***
Comment 12 Shane Caraveo 2008-06-26 11:54:29 PDT
(In reply to comment #10)
> Shane, if you can test this patch as well (and Tristan too, if you have time to
> test yet another patch!), I'd really appreciate it.
> 

It seems to work fine, I'll have a couple other people here test it as well.
Comment 13 Wladimir Palant 2008-06-26 12:14:13 PDT
Note that I have received a large number of bug reports after Firefox 3 release - those might very well be duplicates of this bug or not but I simply don't have the time to investigate all of them. Examples:

https://www.mozdev.org/bugs/show_bug.cgi?id=19414
https://www.mozdev.org/bugs/show_bug.cgi?id=19304
http://adblockplus.org/forum/viewtopic.php?t=2586
http://adblockplus.org/forum/viewtopic.php?t=2539
http://adblockplus.org/forum/viewtopic.php?t=2574
Comment 14 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-26 12:19:48 PDT
This is definitely wanted for 1.9.0.1, it's a regression and it's hurting plugin content developers especially hard (per bug 441424).
Comment 15 Jonas Sicking (:sicking) No longer reading bugmail consistently 2008-06-27 12:05:52 PDT
Comment on attachment 326964 [details] [diff] [review]
Stop double instantiation even earlier.

Are you sure aFrame is never null when nsObjectLoadingContent::HasNewFrame is called?

r/sr=me if so
Comment 16 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-27 12:49:24 PDT
(In reply to comment #15)
> (From update of attachment 326964 [details] [diff] [review])
> Are you sure aFrame is never null when nsObjectLoadingContent::HasNewFrame is
> called?

Yes, the only caller:

http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsObjectFrame.cpp#1060

always passes in |this|, and passing no frame to HasNewFrame() makes no sense to me.
Comment 17 Mike Morearty 2008-06-27 14:40:21 PDT
I just tried the patch, and it looks good to me -- it does fix the problems I was seeing.
Comment 18 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-27 16:36:48 PDT
Awesome, thanks! This was just checked in, closing bug.
Comment 19 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-27 16:39:28 PDT
Comment on attachment 326964 [details] [diff] [review]
Stop double instantiation even earlier.

I've heard several times now in bugzilla and/or private email that this is causing lots of trouble in many plugins. I think it's worth taking on the branch.
Comment 20 Shane Caraveo 2008-06-28 10:10:42 PDT
another potential dup in bug 442479
Comment 21 Shane Caraveo 2008-06-30 07:50:46 PDT
*** Bug 442666 has been marked as a duplicate of this bug. ***
Comment 22 Shane Caraveo 2008-06-30 09:47:13 PDT
(In reply to comment #18)
> Awesome, thanks! This was just checked in, closing bug.
> 

Where was this checked in?  I don't see it in CVS trunk.  Can we get it for 1.9.0.*?
Comment 23 Samuel Sidler (old account; do not CC) 2008-06-30 09:50:05 PDT
(In reply to comment #22)
> Where was this checked in?  I don't see it in CVS trunk.  Can we get it for
> 1.9.0.*?

It was checked in on mozilla-central. There's an approval request for the patch to land in 1.9.0.1.
Comment 24 Tom Finegan 2008-06-30 09:59:32 PDT
The 20080628 Minefield build appeared to have the patch-- at least, the double instantiation behavior had stopped.  The build still leaks instances of plugIn interface objects.  

I'll update bug 434547 re the leaks as they don't really seem to fit in this bug...

Comment 25 Philip Chee 2008-07-19 09:25:08 PDT
Did this ever get checked in on 1.9.0.1?
Comment 26 Samuel Sidler (old account; do not CC) 2008-07-19 15:42:02 PDT
(In reply to comment #25)
> Did this ever get checked in on 1.9.0.1?

No. It got checked into mozilla-central for 1.9.1 and has an approval requested (approval1.9.0.2?) for landing on the 1.9 branch.
Comment 27 Samuel Sidler (old account; do not CC) 2008-07-21 00:06:03 PDT
Anyway we can get a test for this? Maybe from the work in bug 441424?
Comment 28 Philip Chee 2008-07-21 00:22:45 PDT
> Anyway we can get a test for this? Maybe from the work in bug 441424?

Well the test case there involves an extension (greasemonkey) or some way to access nsIContentPolicy and then setting a breakpoint in the debugger, a breakpoint that would bit rot as the code changes.

This bug also caused the regression bug 445520. So perhaps we should wait to see how that is resolved.
Comment 29 Mike Morearty 2008-08-04 15:57:10 PDT
Just wanted to ping this.  At last report (7/19/08), this bug has an approval requested for 1.9.0.2.

I am not really familiar with Mozilla version numbers -- should I think of "1.9.0.2" as roughly corresponding to Firefox 3.0.2?

Also, I take it the approval for 1.9.0.2 is still pending?  I guess basically my point is, I'd like to keep an eye on this bug to make sure it makes it into Firefox 3.0.2, but I don't really understand how I can do that -- e.g. when and where does this approval request get considered.  Thanks!
Comment 30 Samuel Sidler (old account; do not CC) 2008-08-04 16:11:36 PDT
Mike, this will get approved when we have a resolution to bug 445520, which appears to be a regression from this bug.
Comment 31 Wladimir Palant 2008-08-04 16:12:10 PDT
Both is correct - Gecko 1.9.0.2 corresponds with Firefox 3.0.2, and this patch is still waiting for approval to land before Firefox 3.0.2 release :-(
Comment 32 Robert Burke 2008-08-07 11:02:42 PDT
Please see Bug 445599 (apparently a dup of this bug) for another test case around *this* bug.  I also have a working demo of the bug here: http://homepages.rootsweb.ancestry.com/~reburke/work/Firefox3Bug/ff3buginfo.html

Note that in bug 445520 (related to this bug), swfobject 1.5 is mentioned.  I found that upgrading swfobject to 2.1 fixes the problem for me described in *this* bug report.  The basic difference is that swfobject 2.1 embeds flash with an embed tag, whereas swfobject 2.1 embeds flash with an object tag (with nested param tags).  In FF 3.0.1, if you embed flash with an embed tag, and you have certain add-ons such as Greasemonkey, the flash runtime initializes twice due to plugin being initialized twice (see my NSPR logging in Bug 445599).

Anyhow, I think the clue here may be the way in which FF 3.0.1 handles the embed tag, as opposed to how FF 2 handled it.
Comment 33 Robert Burke 2008-08-07 11:06:38 PDT
Correction to previous post:

swfobject 1.5 embeds flash with an embed tag

swfobject 2.1 embeds flash with an object tag
Comment 34 Samuel Sidler (old account; do not CC) 2008-08-15 11:40:37 PDT
Comment on attachment 326964 [details] [diff] [review]
Stop double instantiation even earlier.

Approved for 1.9.0.2. Please land in CVS. a=ss
Comment 35 Johnny Stenback (:jst, jst@mozilla.com) 2008-08-16 17:56:05 PDT
Fix landed in CVS.
Comment 36 Reed Loden [:reed] (use needinfo?) 2008-08-26 23:49:25 PDT
Backed out on CVS HEAD.
Comment 37 Samuel Sidler (old account; do not CC) 2008-08-26 23:50:52 PDT
Comment on attachment 326964 [details] [diff] [review]
Stop double instantiation even earlier.

Pushing this out to 1.9.0.3.
Comment 38 u88484 2008-08-27 08:06:34 PDT
Shouldn't this be reopened then if it was backed out?
Comment 39 Wladimir Palant 2008-08-27 08:26:12 PDT
It wasn't backed out on trunk - only on 1.9 branch. So technically this is still FIXED.
Comment 40 Johnny Stenback (:jst, jst@mozilla.com) 2008-08-27 13:41:11 PDT
:(
Comment 41 Magnus Alström 2008-09-03 02:55:23 PDT
Since this will not be solved until "earliest" 1.9.0.3, we need to update our customers about the progress. 

1. Why is the solution backed out? 
2. What is the time schedule for 1.9.0.3? Q3/Q4-2008 or Q1 2009, any prediction would be nice. 

Currently our solution is to downgrade our end-users to FireFox 2.0, but have no idea how long this will be accepted.
Comment 42 Wladimir Palant 2008-09-03 03:02:52 PDT
(In reply to comment #41)
> 1. Why is the solution backed out? 

Bug 445520

> 2. What is the time schedule for 1.9.0.3? Q3/Q4-2008 or Q1 2009, any
> prediction would be nice.

Minor releases appear roughly once a month - meaning October.
Comment 43 Wladimir Palant 2008-09-03 03:03:57 PDT
Sorry, bug 450949 is the one blocking that right now.
Comment 44 Phillip Whelan 2008-09-08 07:47:08 PDT
Can anyone confirm if this is the same issue as Bug 451816, that bug is still in the unconfirmed stage, it doesn't seem to be related to adblock extensions or anything like that.

This is causing endless amounts of problems for me.
Comment 45 Johnny Stenback (:jst, jst@mozilla.com) 2008-09-08 12:15:48 PDT
This is unrelated to the problem in bug 451816.
Comment 46 Michael Olofsson 2008-09-26 01:36:46 PDT
Was this one included in 3.0.2 or will it be shipped in 3.0.3?
Comment 47 DB Cooper 2008-09-29 07:44:17 PDT
(In reply to comment #46)
> Was this one included in 3.0.2 or will it be shipped in 3.0.3?

I reproduced it last night during browsing (on 3.0.3), so I would say no ... 

Would be nice if it was fixed in 3.0.4
Comment 48 u88484 2008-09-29 07:55:42 PDT
(In reply to comment #47)
> (In reply to comment #46)
> > Was this one included in 3.0.2 or will it be shipped in 3.0.3?
> I reproduced it last night during browsing (on 3.0.3), so I would say no ... 
> Would be nice if it was fixed in 3.0.4

The flag for the patch has "samuel.sidler: approval1.9.0.4?" So they are trying to get approval to land this for Gecko 1.9.0.4 (Firefox 3.0.4)
Comment 49 Samuel Sidler (old account; do not CC) 2008-10-06 11:31:31 PDT
We won't block on this but will look at approval when the regression from bug 445520 (bug 450949) is fixed.
Comment 50 Daniel Veditz [:dveditz] 2008-10-10 11:37:43 PDT
Comment on attachment 326964 [details] [diff] [review]
Stop double instantiation even earlier.

Can't approve this with open regressions. When the regressions are fixed please create a roll-up patch if you're going to request approval
Comment 51 Dave Townsend [:mossop] 2008-11-17 11:44:08 PST
*** Bug 445599 has been marked as a duplicate of this bug. ***
Comment 52 Dave Townsend [:mossop] 2008-11-17 11:44:24 PST
*** Bug 465374 has been marked as a duplicate of this bug. ***
Comment 53 Michael Olofsson 2008-11-21 06:13:08 PST
What is holding this one? Is it 450949?

This one is creating a lot of headache for us to say the least.
Comment 54 John Allberg 2008-12-01 02:01:39 PST
This one is creating a lot of headache for us to say the least.
Comment 55 Daniel Veditz [:dveditz] 2008-12-01 11:27:33 PST
It's way too late for 1.9.0.5, moving out request. But really, it's bug 450949 you need on the list.
Comment 56 Magnus Alström 2008-12-01 11:58:34 PST
How is bug fixing actually supposed to work for this software? This bug was fixed 5 months ago, and have been moved forward a lot of times... Are we supposed to vote for the "blocking" bug or are we supposed to update our support page with a link to this bug, so our customers starts to vote for this bug each time we tell them to downgrade to FireFox 2.0! 

Our problem is that we have quite some installed base on different goverment services using our plugin. Goverment means they are very slow on any type of updates for there web pages, so the only possible workaround is to downgrade the web browser. 

I agree: "This one is creating a lot of headache for us to say the least."
Comment 57 John Allberg 2008-12-11 00:02:22 PST
In the next release of our services we will not accept FF3 users and we will point them to this bug and recommend them to vote.
Comment 58 Daniel Veditz [:dveditz] 2008-12-15 17:47:17 PST
Blocking on this assuming we can take the regression bug 450949 in stride. Will need to take the regression fix in bug 445520 as well.
Comment 59 Daniel Veditz [:dveditz] 2008-12-22 17:42:07 PST
Comment on attachment 326964 [details] [diff] [review]
Stop double instantiation even earlier.

bug 450949 is now resolved by a newer Shockwave, lets try to get this and bug 445520 in.
Comment 60 Michael Olofsson 2009-01-02 00:52:50 PST
What is the status on this one? Implemented or getting ready to?
Comment 61 Daniel Veditz [:dveditz] 2009-01-05 11:27:24 PST
Comment on attachment 326964 [details] [diff] [review]
Stop double instantiation even earlier.

Approved for 1.9.0.6, a=dveditz for release-drivers
Comment 62 Johnny Stenback (:jst, jst@mozilla.com) 2009-01-07 18:42:23 PST
Fix landed in CVS again.
Comment 63 Al Billings [:abillings] 2009-01-14 17:14:15 PST
Verified fixed in 1.9.0.6 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6pre) Gecko/2009011304 GranParadiso/3.0.6pre.
Comment 64 David Tenser [:djst] 2009-03-12 01:36:19 PDT
(In reply to comment #57)
> In the next release of our services we will not accept FF3 users and we will
> point them to this bug and recommend them to vote.

From Jonas Sicking: 

"So there is good news and bad. This bug has been
fixed since Firefox 3.0.6. I just attempted using Firefox 3.0.7 with a
spoofed UA string to look like Firefox 2, and things mostly works. Was
able to install the e-legitimation and use it to log in to the test
site. I was not however able to the e-legitimation to sign something.
The dialog for signing comes up, but I can't type in it or click any
buttons. I just tested in firefox 2 and things work correctly there."

So something is still wrong, but it's no longer this particular bug. Jonas, since it works in Firefox 2, it sounds like we have an opportunity to compare what's going on. Is any help needed from e.g. TeliaSonera at this point?

John Allberg: are you, or could you get us in contact with one of your developers in case we need help finding the cause of this (new) problem? Note: I'm asking on behalf of Jonas Sicking. I'm not a developer myself, but I work from Sweden and you can certainly use my e-mail if you want to get in touch. Also, do you have the link to the error page where you tell customers to vote for this bug? I think that should be replaced with something else as it's probably just confusing/frustrating to customers.

Thanks!
Comment 65 micaela 2009-03-19 06:44:19 PDT
 Bug 438830 plz help me...remove this bug...i cant logg on in my legitimation fr school because of it....what to do???
Comment 66 Johnny Stenback (:jst, jst@mozilla.com) 2009-03-19 10:24:22 PDT
michaela, we'd love to help you, but whoever told you that the reason for not being able to log in because of this bug is wrong because this bug has already been fixed (Status RESOLVED FIXED). Please inform whomever pointed you at this bug that they are referring to the wrong bug, and we need help figuring out what is not working and why with regards to e-legitimation websites. Please help us help you, this bug is NOT the problem.
Comment 67 David Tenser [:djst] 2009-03-19 11:02:24 PDT
Even better, Michaela, could you point out the page that instructed you to visit this bug report? That would be very helpful for us in order to know who we should get in touch with to fix the underlying problem.

Thanks!
Comment 68 Andreas Järliden 2009-03-19 12:52:40 PDT
It is Telia (www.telia.se), a swedish telephone company.  The support number is +46-771-323262 for the electronic id service that claims that this bug prevents them from supporting firefox 3.
Comment 69 David Tenser [:djst] 2009-03-19 13:00:33 PDT
Thanks to Andreas, I finally found the page where Telia links to this bug: https://cve.trust.telia.com/testa/Step2CheckOsBrowser.aspx.

Interestingly, they don't seem to support Safari either, making the choice very limited for users (basically Firefox 2.0!). 

Jonas, Johnny: if you don't disagree, I can call Telia up first thing tomorrow and try to get in touch with one of their developers so we can work together on getting the real problem solved.
Comment 70 Chris Lawson (gone) 2009-03-19 13:03:32 PDT
Can someone please open a TE bug so that we don't have to continue tracking this in a FIXED bug?
Comment 71 Arnaud 2009-03-21 02:23:29 PDT
Hello,
The problem seems to be fixed for you but I have allways the problem.

Here is my test page :
http://www.bauret.be/flash3/readme.html

The first time you open the page you need to click to see the video load in autoplay :-(

Is it the same bug ?
How can I fix it ?

Thx

Arnaud
Comment 72 Arnaud 2009-03-24 10:05:07 PDT
Hello,

No body for my problem plz ?

Thx

Arnaud
Comment 73 Chris Lawson (gone) 2009-03-24 10:07:51 PDT
Arnaud, Bugzilla is not a support forum. Please use the support forums at

http://forums.mozillazine.org/

for support questions.
Comment 74 Terhi 2009-08-26 09:22:40 PDT
2009-03-19  David wrote:

"Jonas, Johnny: if you don't disagree, I can call Telia up first thing tomorrow
and try to get in touch with one of their developers so we can work together on
getting the real problem solved."

Did you call them?  They still ask you to use FF 2 when applying for E-legitimation. I tried today.
My bank SEB, called Telia today and they said the problem remains. Telia still links to this bug http://tinyurl.com/kt9gcl. Maybe there is an another one?

SEB gave me a phone no to call if I wanted:  0771-323262 (Telia, Sweden).

/ Terhi
Comment 75 Jonas Sicking (:sicking) No longer reading bugmail consistently 2009-08-26 10:05:10 PDT
I've talked with people at Telia. The remaining issues are unrelated to this bug, but rather related to changes made to use cocoa widgets in Firefox 3 on Mac. The issue appears to be known on their end, but I don't know what the timeline for fixing it is.

I also asked them to remove the reference to this bug, though maybe that hasn't happened yet?
Comment 76 kverlin 2012-05-02 03:50:37 PDT
I can still see this with Flowplayer in FF12. According to Firebug, flowplayer.swf is loaded twice per player creation.

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