Bug 12050 - REGRESSION: Assertion failure in -[WebBaseNetscapePluginView willCallPlugInFunction] (plugin)
Summary: REGRESSION: Assertion failure in -[WebBaseNetscapePluginView willCallPlugInFu...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Plug-ins (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P1 Major
Assignee: Nobody
URL: http://www.nfc.co.il/Archive/003-D-14...
Keywords: NeedsReduction, Regression
: 12476 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-12-31 14:42 PST by mitz
Modified: 2007-01-30 15:44 PST (History)
2 users (show)

See Also:


Attachments
Reduction (will trip the ASSERT) (313 bytes, text/html)
2007-01-30 08:20 PST, mitz
no flags Details
Proposed fix (3.48 KB, patch)
2007-01-30 09:12 PST, mitz
ggaren: review+
Details | Formatted Diff | Diff
Landable version (3.53 KB, patch)
2007-01-30 15:25 PST, mitz
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2006-12-31 14:42:12 PST
I hit this assert when I open the URL.

ASSERTION FAILED: plugin
(WebKit/Plugins/WebBaseNetscapePluginView.mm:1716 -[WebBaseNetscapePluginView willCallPlugInFunction])
Comment 1 mitz 2007-01-30 07:44:54 PST
*** Bug 12476 has been marked as a duplicate of this bug. ***
Comment 2 mitz 2007-01-30 07:46:23 PST
(In reply to comment #1)
> *** Bug 12476 has been marked as a duplicate of this bug. ***
> 

Copying Priority/Severity and keywords.
Comment 3 mitz 2007-01-30 08:20:08 PST
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.
Comment 4 mitz 2007-01-30 09:12:56 PST
Created attachment 12796 [details]
Proposed fix
Comment 5 Darin Adler 2007-01-30 09:51:20 PST
Comment on attachment 12796 [details]
Proposed fix

r=me
Comment 6 Geoffrey Garen 2007-01-30 11:20:43 PST
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.
Comment 7 Geoffrey Garen 2007-01-30 11:29:10 PST
"... there is no plug-in to load."
Comment 8 mitz 2007-01-30 11:34:01 PST
(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 9 Geoffrey Garen 2007-01-30 12:32:51 PST
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.
Comment 10 mitz 2007-01-30 15:25:17 PST
Created attachment 12815 [details]
Landable version

Corrected tests directory name.
Comment 11 Sam Weinig 2007-01-30 15:44:07 PST
Landed in r19275.