Thanks, I'll do that.
Just so I know for the future, are you saying that you agree this
specific behavior is a bug and that's why I should file it, or are
you saying that the recommended action is to file a bug for any
behavior I feel is wrong or want changed -- whether or not others
agree it's a bug? Your (mis) in parentheses is very nicely ambiguous ;)
Thanks,
Rudi
On Jul 12, 2006, at 8:54 PM, David D. Kilzer wrote:
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
