free (beer) alternatiff plugin doesn't render tiff images correctly at US patent office site.




18 years ago
16 years ago


(Reporter: John D. Griffith, Assigned: av (gone))


Windows NT

Firefox Tracking Flags

(Not tracked)





18 years ago
The alternatiff plugin for rendering tiff images is very useful for viewing the
tiff images of US patents at the USPTO site.  It does not work under Mozilla
M18/NT, as you can check by installing the plugin and trying to view the above
URL.  Install the same plugin with Netscape and check the same URL to see the
correct behavior.  Note that the most current versions of the plugin are
available from  The most current versions
require you to register them the first time that they are used.  I have an older
version that doesn't require this - it also doesn't work under Mozilla M18.  I
can provide the older version and some screenshots showing the problem.  If I
can figure out how to attach them to this bug report, I will.

Comment 1

18 years ago
I've been unable to pin down this problem, but I'm convinced it's a bug in 
Mozilla. Here are some things I've noticed. The behavior has been fairly 
consistent, but with the occasional bit of flakiness, possibly caused by a slow 

- The plugin in question works fine on other web sites.

- This is not specific to any particular TIFF plug-in, and probably not specific 
to the TIFF file type, either. Mozilla is for some reason failing to determine 
the content type of the TIFF document, and therefore not loading a TIFF plug-in 
at all.

- If you figure out the URL of the TIFF image (from the EMBED tag in the 
source), append "&xx=x.tif" to the end of it, and go directly to it, then it 
works. This is a bit scary, because a browser should never ever use an HTTP URL 
to determine a file type, *except* in the very rare case that the document did 
not have a "Content-Type" header. The documents in question do have this header. 
Should I give Mozilla the benefit of the doubt and assume that somehow it is 
losing track of the header, and only then resorting to the emergency backup 
"guess the type by the extension" method?

- If, instead of the patimg[*] hostname, you use the IP address, or 
the alias potw[*], then it works. Say what??!!?? Could Mozilla be 
doing something really absurd like searching for certain strings of characters 
("img"?) in the hostname, and if it finds them, ignoring the "Content-Type" 
header? That's just too bizarre, but even then it can't be that simple, because:

- I cannot reproduce this problem on my own server. Even if I give it a hostname 
of "patimg1.(mydomain)", and create URL that's otherwise exactly the same as one 
that failed, it works fine.

Comment 2

18 years ago
Confirmed with 111004 build on NT.  Plugin doesn't seem to work.
Ever confirmed: true


18 years ago
Keywords: 4xp

Comment 3

18 years ago
The USPTO has modified their site to work around this. Presumably, the bug still 
exists in Mozilla, but I do not know any way to test it.

Comment 4

17 years ago
Marking invalid. Please reopen if there is a testcase.
Last Resolved: 17 years ago
Resolution: --- → INVALID
Target Milestone: --- → Future

Comment 5

16 years ago
spam : marking invalid bugs 'verif'. reopen if u disagree, reporter!
You need to log in before you can comment on or make changes to this bug.