Summary: | REGRESSION: Assertion failure in -[WebBaseNetscapePluginView willCallPlugInFunction] (plugin) | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | mitz | ||||||||
Component: | Plug-ins | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Major | CC: | ggaren, mrowe | ||||||||
Priority: | P1 | Keywords: | NeedsReduction, Regression | ||||||||
Version: | 420+ | ||||||||||
Hardware: | Mac | ||||||||||
OS: | OS X 10.4 | ||||||||||
URL: | http://www.nfc.co.il/Archive/003-D-14305-00.html?tag=20-18-11 | ||||||||||
Attachments: |
|
Description
mitz
2006-12-31 14:42:12 PST
*** Bug 12476 has been marked as a duplicate of this bug. *** (In reply to comment #1) > *** Bug 12476 has been marked as a duplicate of this bug. *** > Copying Priority/Severity and keywords. Created attachment 12793 [details]
Reduction (will trip the ASSERT)
Note that the iframe with display:none isn't strictly necessary: you can reproduce the bug by loading the contents of the iframe into a background tab.
Created attachment 12796 [details]
Proposed fix
Comment on attachment 12796 [details]
Proposed fix
r=me
Comment on attachment 12796 [details]
Proposed fix
Guys, I'm not sure this is the right fix. I think the real bug here is that the plug-in is in the page, and JavaScript holds a reference to it, but it hasn't started yet. Why wasn't -start called?
Here's the bug that I think this doesn't fix: obj.SetVariable("x", 1). That's a valid call to the Flash plug-in, but it would throw an exception because WebKit would think the plug-in hadn't loaded, right?
Or is this fix specific to the case of an <object> element that has no data attribute, so there is plug-in to load?
I'm setting the review flag back to "?" so this doesn't show up in the commit queue for now. Feel free to set it back to "+" if I'm off my rocker.
"... there is no plug-in to load." (In reply to comment #6) > Why wasn't -start called? Because although the plug-in was instantiated, it was not put in a window. Is this conceptually different from the case where the plug-in was not instantiated at all (say because of display:none)? > Or is this fix specific to the case of an <object> element that has no data > attribute, so there is plug-in to load? No. Comment on attachment 12796 [details]
Proposed fix
No, I guess this is no different from display:none, so this fix is probably right.
I'm more confident in it now that I see the original page was trying to access .outerHTML, not the plug-in.
I do still wonder if there are sites out there that break when you load them into background tabs, because doing so makes their plug-ins unscriptable, but I guess we can cross that bridge if we ever come to it.
Created attachment 12815 [details]
Landable version
Corrected tests directory name.
Landed in r19275. |