27775 2009-07-28 13:16:15 -0700 Hiding a <div> by using CSS display:none causes a plug-in within the div to be unloaded losing state. 2022-06-23 18:20:48 -0700 1 1 1 Unclassified WebKit Plug-ins 528+ (Nightly build) All All RESOLVED WONTFIX InRadar P1 Major --- 45049 24346 68072 1 babt webkit-unassigned aestes A.Mueller darin eric mario.bensi mburtin oleg_smirnov pere.martir4 playmobil roc simon.fraser ssseintr2 stuartmorgan zimmermann oldest_to_newest 135337 0 babt 2009-07-28 13:16:15 -0700 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: 135341 1 babt 2009-07-28 13:18:13 -0700 <rdar://problem/7099093> 167300 2 darin 2009-11-30 10:54:32 -0800 It looks like HTML5 requires this. It mentions this in the discussion of <applet>, <embed>, and <object>. 167301 3 darin 2009-11-30 10:55:27 -0800 Unfortunately Radar 7099093 was closed. We'll need to get it reopened or file a new one. 167308 4 simon.fraser 2009-11-30 11:27:09 -0800 <rdar://problem/7430314> 272940 5 eric 2010-09-01 12:41:13 -0700 I'm working on moving more of the plugin management code from the renders to the DOM right now. 275810 6 zimmermann 2010-09-08 07:05:49 -0700 (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 295508 7 darin 2010-10-18 08:18:20 -0700 Bug 39286 is about the same thing, but with an SVG document rather than a plug-in. 337994 8 babt 2011-01-21 03:55:46 -0800 Neither IE nor Firefox exhibit this behavior. Both keep the plug-in loaded. Just ran the test to confirm. 338020 9 mburtin 2011-01-21 05:37:53 -0800 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." 338166 10 darin 2011-01-21 11:03:21 -0800 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. 338168 11 darin 2011-01-21 11:04:06 -0800 Please look at bug 45049 for more details. 338170 12 darin 2011-01-21 11:05:01 -0800 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. 467074 13 ap 2011-09-14 09:33:10 -0700 *** Bug 68072 has been marked as a duplicate of this bug. *** 467711 14 ssseintr2 2011-09-15 02:06:19 -0700 Hi, Is this problem fixed..? Thanks & Regards, Vicky. 481526 15 ssseintr2 2011-10-11 02:19:38 -0700 hi, any updates..? regards, vicky 481535 16 stuartmorgan 2011-10-11 03:04:48 -0700 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. 495058 17 roc 2011-11-02 16:49:16 -0700 (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. 518567 18 eric 2011-12-09 15:14:47 -0800 See https://bugs.webkit.org/show_bug.cgi?id=45049#c7. This is a spec decision. 518616 19 eric 2011-12-09 16:04:19 -0800 (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 518618 20 eric 2011-12-09 16:05:18 -0800 (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. 817655 21 oleg_smirnov 2013-01-28 02:57:10 -0800 Is anybody working for issue? Any solution here? I have one solution with making plugin nonvisible instead of dispaly:none destroying. Is it intresting? 1878077 22 ap 2022-06-23 18:20:48 -0700 Plugin support has been removed from WebKit, so marking as WONTFIX.