Bug 63826 – TIFF plugins sometimes don't work

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Plug-ins

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.

[Adam Roben (:aroben)]

Do you have a particular plugin we can test with?

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/.

[Yair Yogev]

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?

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.

[Yair Yogev]

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 :/

[Yair Yogev]

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?

[Yair Yogev]

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)

[Andy Estes]

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?

[Andy Estes]

Do you see different behavior if you embed your plugin using an <object> instead of an <embed>?

[Yair Yogev]

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.

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.

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

[Yair Yogev]

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

[Yair Yogev]

Andy, if there's other stuff you want us to test in this matter please let us know.

[Andy Estes]

<rdar://problem/10204779>

[Alexey Proskuryakov]

Mass closing plug-in bugs, as plug-in support has been removed from WebKit.

Please comment and/or reopen if this still affects WebKit in some way.