I would suggest filing two bugs: one for the <object> tag (mis)
behavior, and a second for the WebKitOmitPDFSupport not omitting
support for embedded objects.
http://bugzilla.opendarwin.org/
Dave
On Jul 12, 2006, at 7:41 PM, Rudi Sherry wrote:
I'm looking into a problem where embedded PDFs don't invoke a
WebKit plugin.
I found that
<object data="url-to-pdf" ... >
with a "type" property works fine (invokes the PDF plugin), but
<object data="url-to-pdf" type="application/pdf" ... >
simply shows the first page of the PDF in the embedding location as
an image.
I tracked it down to the fact that HTMLObjectEelement::isImageType
() is returning 'true' for "application/pdf"; this happens because
Image::supportsType() looks at all the types that could be an
image. Since it returns TRUE, this becomes a CachedImage and it
never goes out to WebKit to check if any plug-ins support this type.
Image::supportsType() calls +[WebCoreFrameBridge
supportedImageResourceMIMETypes] to get the list. There is also +
[WebCoreFrameBridge supportedImageMIMETypes], which is the same
list except specifically excluding the hard-coded strings
"application/pdf" and "application/postscript".
Does anyone know why are there two different methods for returning
the image mime types -- whose only difference are the pdf/
postscript types? Neither are called from within WebCore itself.
Another tantalizing tidbit is that there is a hidden preference
"WebKitOmitPDFSupport", used by WebKit (but not WebCore), that will
remove some built-in PDF support from numerous places... but not,
unfortunately, from embedded objects as they're being parsed.
Does anyone on this list know more about the history or design of
all this?
Thanks,
Rudi
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
