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
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
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
Sorry for the ambiguity! :) I'm not able to judge whether the behavior you described is correct or not (although on the surface they do seem like bugs to me), but I think you will get a lot more feedback if you file bugs in Bugzilla. The developers (both Apple engineers and open source developers) are much more active on Bugzilla (and IRC) than on this mailing list. http://webkit.opendarwin.org/contact.html Dave On Thu, Jul 13, 2006 at 09:05:50AM -0700, Rudi Sherry wrote:
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
participants (2)
-
David D. Kilzer
-
Rudi Sherry