Bug 63826 - TIFF plugins sometimes don't work
Summary: TIFF plugins sometimes don't work
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Plug-ins (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows XP
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2011-07-01 12:11 PDT by js2578
Modified: 2011-09-28 17:20 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description js2578 2011-07-01 12:11:32 PDT
NPAPI plugins for TIFF documents don't work in <embed> tags if the attribute "type=image/tiff" is used. The region of the web page where the plugin should appear is blank.

Exception: A TIFF plugin will always work if its "ProductName" contains the substring "quicktime". ("ProductName" is an attribute in the VERSION resource of the plugin's DLL file.)

Tested with WebKit-r89815 (2011-06-27).

I note that according to bug 20244, there is (or at least was) special logic regarding TIFF documents.
Comment 1 Adam Roben (:aroben) 2011-07-05 06:14:45 PDT
Do you have a particular plugin we can test with?
Comment 2 js2578 2011-07-05 07:03:31 PDT
Ideally, you'd use a test plugin that you can recompile yourself, so you can change the ProductName. I don't have such a thing prepared. If you just need to reproduce the main problem, try the plugin at http://www.alternatiff.com/.
Comment 3 Yair Yogev 2011-08-04 17:16:34 PDT
was it always that way (since you first tried to port alternatiff to work with webkit/chrome) or is that some kind of a regression we can try tracking?
Comment 4 js2578 2011-08-05 12:09:40 PDT
TIFF plugins worked correctly in Chrome until about March 2010. For a while, we worked around it by spoofing QuickTime. That ultimately caused too many problems, and we were under the (apparently mistaken) impression that the bug had been fixed, so we stopped doing that.
Comment 5 Yair Yogev 2011-08-05 14:48:42 PDT
According to my tests this regression happened during March 2011 (not 2010)

Works:
Chromium 12.0.718.0 (Developer Build 79660) WebKit 534.27 (trunk@81970) V8 3.2.5

FAIL:
Chromium 12.0.719.0 (Developer Build 79668) WebKit 534.27 (trunk@82221) V8 3.2.5

this is the relevant chrome changelog which leads me to assume this is indeed a WebKit regression
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=%2Ftrunk%2Fsrc&range=79660%3A79668&mode=html

and this is the relevant WebKit changelog:
http://trac.webkit.org/log/?rev=82221&stop_rev=81970&verbose=on

i couldn't spot any immediate suspects in that changelog though :/
Comment 6 Yair Yogev 2011-08-05 16:40:36 PDT
correction for the WebKit changelog (only showed the first 100):
http://trac.webkit.org/log/?action=stop_on_copy&mode=stop_on_copy&rev=82221&stop_rev=81970&limit=300&verbose=on

there are some possible suspects in this changelog, 

the most likely is http://trac.webkit.org/changeset/82001/

Andy Estes, can you take a look?
Comment 7 Yair Yogev 2011-08-05 16:48:35 PDT
btw the test case i used for this is 
http://www.alternatiff.com/testpage.html with AlternaTIFF plugin (see http://www.alternatiff.com/ ) in Chromium under Windows.

test 1 works there but test2 and test3 does not (apparently after r82001)
Comment 8 Andy Estes 2011-08-05 17:09:40 PDT
I'll take a look at this. A few random thoughts that come to mind:

1) r82001 changed our logic for <embed> to prefer a plug-in over native rendering for image types. We want to give plug-ins a chance to render an image before we render it natively.

2) QuickTime does support image/tiff, but if another plug-in also registers support for this MIME type, we will use this plug-in instead.

Given these two facts, it is possible that before r82001 the <embed> was being rendered natively (or by QuickTime) and after r82001 it is being rendered by your plug-in. Have you ruled out a bug in the plug-in being responsible for the intermittent failure?
Comment 9 Andy Estes 2011-08-05 17:13:56 PDT
Do you see different behavior if you embed your plugin using an <object> instead of an <embed>?
Comment 10 Yair Yogev 2011-08-05 23:04:45 PDT
Thanks for looking into this.
I can answer #8 partially: When AlternaTiff renders a Tif file it has a toolbar which gives it a distinctive look, for that reason i can tell for sure that in my tests it was  AlternaTiff loading it. Also, AFAIK Chromium can't render tiff files natively and i disabled QuickTime in my tests (because it's quicker than look for the place to set it not to open Tif files specifically, so AlternaTiff can kick in. I'm not sure why QuickTime has precedence though).
In my tests i didn't observe an intermittent failure- it was consistently failing test2 & 3 and passing test1 in http://www.alternatiff.com/testpage.html after r82001.

js2578 will be able to give more insight.
Comment 11 js2578 2011-08-07 17:03:59 PDT
If the March 2010 issue was separate from the March 2011 issue, it's possible I've given you some misinformation. If so, I apologize. I'll do some more testing. I don't know what all factors the issue depends on, but it probably doesn't depend on the actual plugin executable code, since Chrome doesn't seem to attempt to run the plugin at all.
Comment 12 js2578 2011-08-08 11:02:19 PDT
I think my report was okay, though I'd add that I'm assuming you don't have the QuickTime TIFF plugin installed. Also, Webkit and Chrome behave quite differently from each other in some cases.

Here are some test results of different methods of displaying an image, with a plugin whose ProductName does not contain the string "quicktime".

=== WebKit r92573 (8/Aug/2011)
 <embed type="image/tiff">: Blank
 <embed> without "type" param: Uses plugin
 <object type="image/tiff">: Displays "Missing Plug-in"
 <object> without type: Uses internal viewer
 <img>: Uses internal viewer
 <iframe>: Uses internal viewer
 View directly: Uses internal viewer

=== Chrome 13.0.782.107
 <embed type="image/tiff">: Blank
 <embed> without "type" param: Uses plugin
 <object type="image/tiff">: Uses plugin
 <object> without type: Uses plugin
 <img>: "Broken image" icon
 <iframe>: Displays a dark gray rectangle
 View directly: Displays a dark gray rectangle
Comment 13 Yair Yogev 2011-08-08 11:13:13 PDT
well you tried an "old" version of chrome. the latest chromium build from 
http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?path=Win/&sort=desc
might bring different (and more accurate) results
Comment 14 Yair Yogev 2011-09-28 17:01:59 PDT
Andy, if there's other stuff you want us to test in this matter please let us know.
Comment 15 Andy Estes 2011-09-28 17:20:06 PDT
<rdar://problem/10204779>