Bug 12050

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:

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	Flags
Reduction (will trip the ASSERT)	none
Proposed fix	ggaren: review+
Landable version	none

mitz

Reported 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])

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
View All Add attachment proposed patch, testcase, etc.

mitz

Comment 1 2007-01-30 07:44:54 PST

*** Bug 12476 has been marked as a duplicate of this bug. ***

mitz

Comment 2 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.

mitz

Comment 3 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.

mitz

Comment 4 2007-01-30 09:12:56 PST

Created attachment 12796 [details] Proposed fix

Darin Adler

Comment 5 2007-01-30 09:51:20 PST

Comment on attachment 12796 [details] Proposed fix r=me

Geoffrey Garen

Comment 6 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.

Geoffrey Garen

Comment 7 2007-01-30 11:29:10 PST

"... there is no plug-in to load."

mitz

Comment 8 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.

Geoffrey Garen

Comment 9 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.

mitz

Comment 10 2007-01-30 15:25:17 PST

Created attachment 12815 [details] Landable version Corrected tests directory name.

Sam Weinig

Comment 11 2007-01-30 15:44:07 PST

Landed in r19275.

Note You need to log in before you can comment on or make changes to this bug.