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