Bug 12050 – REGRESSION: Assertion failure in -[WebBaseNetscapePluginView willCallPlugInFunction] (plugin)

• Status: RESOLVED
• Resolution: FIXED
• Component: Plug-ins

I hit this assert when I open the URL.

ASSERTION FAILED: plugin
(WebKit/Plugins/WebBaseNetscapePluginView.mm:1716 -[WebBaseNetscapePluginView willCallPlugInFunction])

*** 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

[Darin Adler]

Comment on attachment 12796 [details]
Proposed fix

r=me

[Geoffrey Garen]

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.

[Geoffrey Garen]

"... 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.

[Geoffrey Garen]

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.

[Sam Weinig]

Landed in r19275.