David D. Kilzer
ddkilzer at kilzer.net
Wed Jul 12 20:54:08 PDT 2006
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.
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?
More information about the webkit-dev