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:
<rdar://problem/7099093>
It looks like HTML5 requires this. It mentions this in the discussion of <applet>, <embed>, and <object>.
Unfortunately Radar 7099093 was closed. We'll need to get it reopened or file a new one.
<rdar://problem/7430314>
I'm working on moving more of the plugin management code from the renders to the DOM right now.
(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
Bug 39286 is about the same thing, but with an SVG document rather than a plug-in.
Neither IE nor Firefox exhibit this behavior. Both keep the plug-in loaded. Just ran the test to confirm.
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."
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.
Please look at bug 45049 for more details.
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.
*** Bug 68072 has been marked as a duplicate of this bug. ***
Hi, Is this problem fixed..? Thanks & Regards, Vicky.
hi, any updates..? regards, vicky
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.
(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.
See https://bugs.webkit.org/show_bug.cgi?id=45049#c7. This is a spec decision.
(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
(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.
Is anybody working for issue? Any solution here? I have one solution with making plugin nonvisible instead of dispaly:none destroying. Is it intresting?
Plugin support has been removed from WebKit, so marking as WONTFIX.