Bug 12778

Summary: REGRESSION: Nightly won't load Curl plugin for full page use
Product: WebKit Reporter: William Bardwell <wbardwel>
Component: Plug-insAssignee: Alexey Proskuryakov <ap>
Status: VERIFIED FIXED    
Severity: Major CC: andersca, ap
Priority: P1 Keywords: InRadar, Regression
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
Attachments:
Description Flags
proposed fix darin: review+

William Bardwell
Reported 2007-02-15 15:14:21 PST
A Nightly from Feb 14 2007 won't load my plugin if you browse to a URL that is for a file handled by the plugin. The plugin is listed in the Installed Plugin-ins page, and I do seem to be able to load flash stuff from a .swf url. This plugin works in Safari 2.0.4 419.3, and it works if used from an OBJECT tag.
Attachments
proposed fix (2.64 KB, patch)
2007-03-31 10:22 PDT, Alexey Proskuryakov
darin: review+
David Kilzer (:ddkilzer)
Comment 1 2007-02-15 15:21:52 PST
Is this a Netscape plug-in? If so, does it work in Firefox on the same Mac? Are there any error/warning messages that appear on the console or in a log file when you try to load a file that uses the plug-in? What does the Activity window show?
Alexey Proskuryakov
Comment 2 2007-02-15 21:59:33 PST
And, most importantly - is there a way for us to reproduce the problem? If confirmed, this would be a P1 bug.
William Bardwell
Comment 3 2007-02-17 16:10:22 PST
You can download a version of my product and go to demos that use it at: www.curl.com It works with 419.3 but not with a recent nightly.
Alexey Proskuryakov
Comment 4 2007-02-18 02:48:15 PST
The problem here is that WebHTMLView claims support for all "text/" MIME types, and +[WebView _viewClass:andRepresentationClass:forMIMEType:] doesn't even look at plugins if internal support is found. It's easy to suggest a number of easy fixes for this, but choosing the correct one may be more tricky.
Maciej Stachowiak
Comment 5 2007-02-19 19:46:37 PST
What MIME type does this plugin want to use?
William Bardwell
Comment 6 2007-02-19 21:56:11 PST
The key type is "text/vnd.curl" (but it registers some others that are only ever used for plugin detection JavaScript code.)
Maciej Stachowiak
Comment 7 2007-02-27 19:33:54 PST
Alexey Proskuryakov
Comment 8 2007-03-31 10:22:01 PDT
Created attachment 13911 [details] proposed fix My diagnosis was wrong - it's fine for +[WebView _viewClass:andRepresentationClass:forMIMEType:] to return WebHTMLView/WebHTMLRepresentation, as plugins are also handled by these. The actual problem seems to be in DOMImplementation::createDocument(), which hates plugins (it also mishandles Adobe SVG and any xml MIME types now). I don't know how to make a test for this fix.
Darin Adler
Comment 9 2007-03-31 17:35:39 PDT
Comment on attachment 13911 [details] proposed fix Looks good. r=me
Alexey Proskuryakov
Comment 10 2007-03-31 22:58:59 PDT
Committed revision 20648.
William Bardwell
Comment 11 2007-04-03 20:46:56 PDT
This does fix the problem for me. (To make a test, you need a plugin that tries to take text/<something> and make sure that it gets loaded if you load a url with that as the mime-type.)
Alexey Proskuryakov
Comment 12 2007-04-03 21:37:47 PDT
(In reply to comment #11) > This does fix the problem for me. Great - so, marking as VERIFIED. IIRC, this problem was blocking you from verifying some other plugin issues with TOT (nightly) - could you please check those? > (To make a test, you need a plugin that tries to take text/<something> and > make sure that it gets loaded if you load a url with that as the mime-type.) Yes, that's how I tested when making this patch - but this doesn't translate into automated test easily, because the plugin has to be full page.
Note You need to log in before you can comment on or make changes to this bug.