63826 2011-07-01 12:11:32 -0700 TIFF plugins sometimes don't work 2022-07-01 11:36:05 -0700 1 1 1 Unclassified WebKit Plug-ins 528+ (Nightly build) PC Windows XP RESOLVED WONTFIX InRadar P2 Normal --- 0 js2578 webkit-unassigned aestes andersca ap aroben eric progame+wk oldest_to_newest 431323 0 js2578 2011-07-01 12:11:32 -0700 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. 432242 1 aroben 2011-07-05 06:14:45 -0700 Do you have a particular plugin we can test with? 432263 2 js2578 2011-07-05 07:03:31 -0700 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/. 446911 3 progame+wk 2011-08-04 17:16:34 -0700 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? 447327 4 js2578 2011-08-05 12:09:40 -0700 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. 447432 5 progame+wk 2011-08-05 14:48:42 -0700 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 :/ 447471 6 progame+wk 2011-08-05 16:40:36 -0700 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? 447477 7 progame+wk 2011-08-05 16:48:35 -0700 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) 447483 8 aestes 2011-08-05 17:09:40 -0700 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? 447484 9 aestes 2011-08-05 17:13:56 -0700 Do you see different behavior if you embed your plugin using an <object> instead of an <embed>? 447577 10 progame+wk 2011-08-05 23:04:45 -0700 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. 447779 11 js2578 2011-08-07 17:03:59 -0700 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. 448108 12 js2578 2011-08-08 11:02:19 -0700 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 448125 13 progame+wk 2011-08-08 11:13:13 -0700 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 475089 14 progame+wk 2011-09-28 17:01:59 -0700 Andy, if there's other stuff you want us to test in this matter please let us know. 475106 15 aestes 2011-09-28 17:20:06 -0700 <rdar://problem/10204779> 1879999 16 ap 2022-07-01 11:36:05 -0700 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.