Bug 27775

Summary: Hiding a <div> by using CSS display:none causes a plug-in within the div to be unloaded losing state.
Product: WebKit Reporter: Bill Abt <babt>
Component: Plug-insAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Major CC: aestes, A.Mueller, darin, eric, mario.bensi, mburtin, oleg_smirnov, pere.martir4, playmobil, roc, simon.fraser, ssseintr2, stuartmorgan, zimmermann
Priority: P1 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on: 45049    
Bug Blocks: 24346, 68072    

Description Bill Abt 2009-07-28 13:16:15 PDT
Summary: 
Hiding a <div> by using CSS display:None causes a plug-in within the div to be unloaded losing state.

Steps to Reproduce:
1.  Create an html page containing a <div> with a Quicktime plug-in <object> tag inside pointing to a local movie that starts playing when the page is loaded.
2.  Add two buttons, "Show" and "Hide".
3.  Add JS method for "Show" that shows the div by resetting the div.style.display property to "".
4.  Add JS method for "Hide" that hides the div setting the div.style.display property to "none".
5.  Save the html to an Apache WebServer.
6.  Load the page in Safari.
7.  Let movie run a few seconds and pause using the QT control.
8.  Click the "Hide" button.
9.  Click the "Show" button.

Expected Results:
At the end of step 9 above, expect to be able to resume the movie at the point where it was paused before hiding the div.

Actual Results:
Movie starts from the beginning.

Regression:
Does not seem to be a regression.  Can reproduce on latest Safari 3 as well Safari 4.

Notes:
It's not just the Quicktime plug-in that gets unloaded under these circumstances, it's any plug-in.

Apple Bug:
Comment 1 Bill Abt 2009-07-28 13:18:13 PDT
<rdar://problem/7099093>
Comment 2 Darin Adler 2009-11-30 10:54:32 PST
It looks like HTML5 requires this. It mentions this in the discussion of <applet>, <embed>, and <object>.
Comment 3 Darin Adler 2009-11-30 10:55:27 PST
Unfortunately Radar 7099093 was closed. We'll need to get it reopened or file a new one.
Comment 4 Simon Fraser (smfr) 2009-11-30 11:27:09 PST
<rdar://problem/7430314>
Comment 5 Eric Seidel (no email) 2010-09-01 12:41:13 PDT
I'm working on moving more of the plugin management code from the renders to the DOM right now.
Comment 6 Nikolas Zimmermann 2010-09-08 07:05:49 PDT
(In reply to comment #5)
> I'm working on moving more of the plugin management code from the renders to the DOM right now.

Hi Eric,

excellent news. I got a bug report regarding Dojo & Tabs.
They are using an <embed> in one tab, and another unrelated second tab.
When I switch from the first tab to the second one, Dojo sets display="none" on the first tab, and the RenderEmbeddedObject is destructed, when switching back the tabs the referenced document (through <embed>) is reloaded, and thus all dynamic DOM changes are not preserved.

None of the other browsers do this.
They guys are going to file a bug soon.

Cheers,
Niko
Comment 7 Darin Adler 2010-10-18 08:18:20 PDT
Bug 39286 is about the same thing, but with an SVG document rather than a plug-in.
Comment 8 Bill Abt 2011-01-21 03:55:46 PST
Neither IE nor Firefox exhibit this behavior.  Both keep the plug-in loaded.  Just ran the test to confirm.
Comment 9 Michaël Burtin 2011-01-21 05:37:53 PST
I plan to work on this bug to provide a patch but as I may not be able to do this without your hints, suggestions and recommendations on how to get plugin code out of rendering tree.

According to current HTML5 spec, plugin life-cycle should not be affected by CSS properties (on embed, object and applet elements).
http://dev.w3.org/html5/spec/Overview.html#dfnReturnLink-44
"The embed element is unaffected by the CSS 'display' property. The selected plugin is instantiated even if the element is hidden with a 'display:none' CSS style."
http://dev.w3.org/html5/spec/Overview.html#dfnReturnLink-156
"The above algorithm is independent of CSS properties (including 'display', 'overflow', and 'visibility'). For example, it runs even if the element is hidden with a 'display:none' CSS style, and does not run again if the element's visibility changes."
http://dev.w3.org/html5/spec/Overview.html#the-applet-element
"The applet element is unaffected by the CSS 'display' property. The Java Language runtime is instantiated even if the element is hidden with a 'display:none' CSS style."
Comment 10 Darin Adler 2011-01-21 11:03:21 PST
The key to fixing this is making the plug-in loading be driven by the DOM elements rather than the renderer. Finding the right DOM class to put this in could be a challenge. We may need to create an object that hangs off the DOM to share the code in.

The key to successfully fixing is it to greatly increase the number of plug-in-related tests and to find a way to do the work incrementally instead of one patch.
Comment 11 Darin Adler 2011-01-21 11:04:06 PST
Please look at bug 45049 for more details.
Comment 12 Darin Adler 2011-01-21 11:05:01 PST
Generally speaking it’s best to fix some smaller scale bugs first. This particular bug is probably not a good choice for a newcomer to the WebKit project.
Comment 13 Alexey Proskuryakov 2011-09-14 09:33:10 PDT
*** Bug 68072 has been marked as a duplicate of this bug. ***
Comment 14 ssseintr 2011-09-15 02:06:19 PDT
Hi,

Is this problem fixed..?

Thanks & Regards,
Vicky.
Comment 15 ssseintr 2011-10-11 02:19:38 PDT
hi,

any updates..?

regards,
vicky
Comment 16 Stuart Morgan 2011-10-11 03:04:48 PDT
If the bug were fixed, the Status field would say it was fixed. If there were updates, you'd see them in the comment stream--and you'd have received an email, since you are CCd.

Please don't spam bugs.
Comment 17 Robert O'Callahan 2011-11-02 16:49:16 PDT
(In reply to comment #8)
> Neither IE nor Firefox exhibit this behavior.  Both keep the plug-in loaded.  Just ran the test to confirm.

That's odd. Firefox definitely uninstantiates display:none plugins.
Comment 18 Eric Seidel (no email) 2011-12-09 15:14:47 PST
See https://bugs.webkit.org/show_bug.cgi?id=45049#c7.  This is a spec decision.
Comment 19 Eric Seidel (no email) 2011-12-09 16:04:19 PST
(In reply to comment #17)
> (In reply to comment #8)
> > Neither IE nor Firefox exhibit this behavior.  Both keep the plug-in loaded.  Just ran the test to confirm.
> 
> That's odd. Firefox definitely uninstantiates display:none plugins.

Roc is referring to:
https://bugzilla.mozilla.org/show_bug.cgi?id=697651
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033732.html
Comment 20 Eric Seidel (no email) 2011-12-09 16:05:18 PST
(In reply to comment #17)
> (In reply to comment #8)
> > Neither IE nor Firefox exhibit this behavior.  Both keep the plug-in loaded.  Just ran the test to confirm.
> 
> That's odd. Firefox definitely uninstantiates display:none plugins.

Interesting that FF appears not to uninstantiate display: none frames:  See webkit bug 39286.
Comment 21 Oleg Smirnov 2013-01-28 02:57:10 PST
Is anybody working for issue? Any solution here?
I have one solution with making plugin nonvisible instead of dispaly:none destroying. Is it intresting?
Comment 22 Alexey Proskuryakov 2022-06-23 18:20:48 PDT
Plugin support has been removed from WebKit, so marking as WONTFIX.