[Webkit-unassigned] [Bug 10015] objects with TYPE="application/pdf" only use internal PDF image, don't use PDf plugins

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Apr 16 22:46:29 PDT 2007


http://bugs.webkit.org/show_bug.cgi?id=10015





------- Comment #6 from j at apple.com  2007-04-16 22:46 PDT -------
(In reply to comment #5)
> (In reply to comment #4)
> 
> I think we have a philosophical difference.
> 
> I like the flexibility where I can create plug-ins to handle almost anything. 
> Plug-ins are used to extend and customize behavior, based on mimetype; saying
> that there are a certain set of mimetypes that are simply off-limits to
> plug-ins seems arbitrary to me, especially when we decide there are a few that
> need special behavior.  Indeed, we don't even know what the list is since it
> includes "anything an NSImage can handle" and that set of mimetypes may
> increase in the future.
> 
> Why is it awful that Quicktime handles PNG?  I don't know any details about
> what makes it awful, but I believe it's really a Quicktime problem, and it is
> not an indication that allowing it is bad architecture. 
> 
> Given all that, though, for performance and other practical reasons I'm willing
> to go along with the status quo and add the loophole specifically for
> application/pdf; I'd like to put my two cents in, though, to structure the bug
> fix such that it can someday be extended to all mime types.
> 

Rudi Sherry from Adobe says:

Reader 8 on the mac can now work embedded in HTML documents, using the <object>
or <embed> html objects.  There are increasing numbers of workflows using this
mechanism now that there is support for bidirectional javascript between the
PDF and the html DOM.

Unfortunately, any object with type="application/pdf" will not load Reader in
the current Safari because the WebKit gives preference to the innate PDF image
type in Mac OS X; this means that until this bug is fixed, web servers won't be
able to support Safari or webkit-based applications for these workflows.

Here's my take on the issue.

The documented and expected behavior of the "type" attribute for the OBJECT tag
is as follows:

This attribute specifies the content type for the data specified by data. This
attribute is optional but recommended when data is specified since it allows
the user agent to avoid loading information for unsupported content types. If
the value of this attribute differs from the HTTP Content-Type returned by the
server when the object is retrieved, the HTTP Content-Type takes precedence.

http://www.w3.org/TR/html401/struct/objects.html#adef-type-OBJECT

My thinking is that WebKit should properly support it (other browsers do,
according to the definition above) and we really need it for SAP support. SAP
relies heavily on the in-built scripting support inside Adobe Reader 8 and
other features specific to Adobe Reader 8. Showing an 'image' or the first page
of the PDF won't help SAP.

Certainly something needs to be done, since right now using the 'type'
attribute causes a blank page to show in WebKit which is definitely wrong
behavior. (the PDF object is present but you can't see it)


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list