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 http://www.mieweb.com/alternatiff/. 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.
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 server. - 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[*].uspto.gov hostname, you use the IP address, or the alias potw[*].uspto.gov, 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.
Confirmed with 111004 build on NT. Plugin doesn't seem to work.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Marking invalid. Please reopen if there is a testcase.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
Target Milestone: --- → Future
spam : marking invalid bugs 'verif'. reopen if u disagree, reporter!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.