Assuming a TIFF plug-in (such as QuickTime) is installed in Mozilla, links directly to TIFF documents that include a TARGET attribute often don't work correctly. If the TARGET is "_blank" or a user-defined name, Mozilla opens a new blank window, but then loads the plug-in into the *original* window. If the TARGET is "_self", Mozilla loads the plug-in into the correct window, but sometimes fails to send the TIFF document to the plug-in. It appears to send a bunch of NUL bytes instead. Stranger, this problem does not seem to occur for TIFFs with a small file size -- they work fine. I found the threshhold to be around 9160 bytes, but I don't think it was 100% consistent. "image/tiff" is the only document type I found that exhibits these problems. Other types work correctly. I suspect this is somehow related to bug 88692, but that one's been fixed.
Which version of QuickTime are you using? (Start => Settings => Control Panel => QuickTime => About)
Sounds like a possible chunked transfer problem....
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm using QuickTime 5.0.2, but I don't think it matters. I get exactly the same behavior with other image/tiff plug-ins. What may make a difference is whether the plug-in uses streaming vs "StreamAsFile" reads. The plug-ins I've tested probably use streaming. Links without a target attribute apparently behave the same as "_self" (as they should) -- I don't know why I didn't recognize that before. I guess maybe this should be two separate bugs. But why does "image/tiff" need to be hardcoded into Mozilla at all?
I've filed some new bugs to replace this one, and attempt to clarify the situation: bug 153452, bug 153454, bug 153451 *** This bug has been marked as a duplicate of 153452 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
mass duplicate verifications . For filtering purposes, pls use keywd "massdupverification"
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.