src path starting with a "/." causes TIFFs (via QuickTime Plug-in) to display as blank (USPTO patents)

RESOLVED INCOMPLETE

Status

()

Core
Plug-ins
--
major
RESOLVED INCOMPLETE
15 years ago
5 years ago

People

(Reporter: flip@skidmore.edu, Unassigned)

Tracking

({testcase})

Trunk
All
Mac OS X
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021230 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021230 Chimera/0.6+

Attempting to load TIFF images via the QuickTime Plug-in fails on images from
the USPTO patent search site (see above for example). The USPTO uses Group 4
compressed 300 dpi images (http://65.202.253.39/patft/images.htm). These load
fine in Explorer 5.2.2. Chimera displays a broken-image icon.

Reproducible: Always

Steps to Reproduce:
1. Go to a web page that has Group 4 TIFF images imbeded (for example, USPTO)
2. Attempt to load image
5. 

Actual Results:  
Doesn't load (broken QT-Document Icon)

Expected Results:  
Shown image

Comment 1

15 years ago
Confirming issue in the 2003-01-01-04. The problem is the relative path used in
the EMBED tag's src value. The src path starts with a "/." which I believe is
causing us to give the plugin a incorrect path.Other tiff images work from
additional sites so it's not general tiff issue. Attaching reduced test case.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

15 years ago
Created attachment 110519 [details]
Reduced test case 

Plugin will show a "broken" icon on this test case. The EMBED tag src uses a
"/." at the beginning of it's path which I believe is the cause.

Comment 3

15 years ago
Confirming. This works fine in IE.

Comment 4

15 years ago
I just wanted to confirm this type of TIFF bug
with:
Build ID: 2003031008
on Win XP Home   (the OS came with the laptop... sorry, at least I installed
Mozilla ;)

I tried doing a Patent search for on
http://patft.uspto.gov/netahtml/srchnum.htm
for Patent Number: 334823
I got a partical image
but not the full image


ok, I'm not sure how to submit a bug (and I'm lazy ;)
but I did search for a similar bug and I found this one

I was a little dissappointed when I could just ADD another OS (and hardware
type) to this type of bug..... maybe I just missed something... or maybe I found
a bug/wishlist item.... but I would imagine that there would be a way to just
add to the existing bug... with a "similar" experience

if anyone checks this, PLEASE let me know what I should do (if I'm doing
something wrong) or just tell me it's all good, the bug has been updated with my
new info...
Thanks and I LOVE Open source (sorry if my comments were out of place)
g

Comment 5

15 years ago
hm...the testcase is even causing problems in Win32 and even in IE....

Comment 6

15 years ago
I can confirm the same behavior with the Patents Office site using Camino 20030324 nightly build.

I also generated a compress TIFF and stuck it on an Apache server, then used Camino to click on the image link. It worked fine.

But, Camino crashes if I go to a FUDforum site and try to click on an attachment TIFF image.

Comment 7

13 years ago
Could somebody please update, the attached test case cause a crash in camino
2004100808 (v0.8+) NB cause by a Quicktime bug.

Comment 8

13 years ago
Testcase causes repeatable crash in Firefox 1.0 OSX. See talkback incidents
TB3161304Q and TB3161343K. See also bug 255767 for a different USPTO TIFF problem.

Here's the first few lines of the crash log:

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xf26f9416

Thread 0 Crashed:
0   ...ickTimeComponents.component 	0x8b3e66f0 DecompressStrip_Fax + 0x144
1   ...ickTimeComponents.component 	0x8b3df1a8 TIFF_DBandDecompress + 0x210
2   ...ple.CoreServices.CarbonCore 	0x90282474 CallComponentFunctionCommon + 0x414
3   ...ickTimeComponents.component 	0x8b3e7c40 TIFF_DComponentDispatch + 0x58
4   ...ple.CoreServices.CarbonCore 	0x902811e0 CallComponent + 0x10c
5   com.apple.QuickTime            	0x91bc71e0 ImageCodecBandDecompress + 0x28
6   com.apple.QuickTime            	0x91bb6dd4 DoBandedDecompress + 0x26e0
Severity: normal → critical
Component: Plug-ins → Plug-ins
Keywords: crash
Product: Camino → Core
Summary: TIFF support in QuickTime Plug-in seems broken → TIFF support in QuickTime Plug-in broken (Decompress)
Version: unspecified → Trunk

Comment 9

12 years ago
*** Bug 187115 has been marked as a duplicate of this bug. ***

Comment 10

12 years ago
You guys still seeing this in Firefox 1.5?

Comment 11

12 years ago
(In reply to comment #10)
> You guys still seeing this in Firefox 1.5?
> 

Yes. The reduced test case causes a serious problem in the plugin. Not a crash, but you get a warning dialog that tells you to close Firefox.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
QuickTime Plug-in 7.0.3

Comment 12

12 years ago
that dialog means a plugin crashed (we have an exception handler that tries to handle that kind of crash, but it really is a crash).
Summary: TIFF support in QuickTime Plug-in broken (Decompress) → TIFF support in QuickTime Plug-in broken (Decompress) [@ DecompressStrip_Fax + 0x144]

Comment 13

11 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.5) Gecko/20060705 Firefox/1.5.0.5

This bug is present in both Mozilla 1.7.13 and Firefox 1.8.0.5.

Comment 14

11 years ago
*** Bug 307199 has been marked as a duplicate of this bug. ***
Keywords: testcase
I don't see any crashes with QT 7.6.2 on 10.5.7, but the bug as originally filed and confirmed (comment 0-3) still exists; we load the plug-in and then display a completely blank screen.

Safari 4 will happily load the image ("Search timeout expired"), apparently using its native TIFF support even in <embed>.  However, I also checked Opera 9.6 and the non-WebKit iCab 3, and they both display the image as expected, too, using the QT plug-in.
Assignee: peterlubczynski-bugs → nobody
QA Contact: chrispetersen → plugins
Hardware: PowerPC → All
Summary: TIFF support in QuickTime Plug-in broken (Decompress) [@ DecompressStrip_Fax + 0x144] → src path starting with a "/." causes TIFF (via QuickTime Plug-in) not to load (Decompress) [@ DecompressStrip_Fax + 0x144]

Updated

8 years ago
Keywords: crash
Summary: src path starting with a "/." causes TIFF (via QuickTime Plug-in) not to load (Decompress) [@ DecompressStrip_Fax + 0x144] → src path starting with a "/." causes TIFF (via QuickTime Plug-in) to show blank (not Decompress?)

Updated

8 years ago
Severity: critical → major
I discovered today, following up on the recent MacInTouch comments on this, that simply scrolling the page gets the TIFF to display for me (Camino 2.0.1 on 10.5.8, QT 7.6.4).
Summary: src path starting with a "/." causes TIFF (via QuickTime Plug-in) to show blank (not Decompress?) → src path starting with a "/." causes TIFF (via QuickTime Plug-in) to show blank (USPTO patents)
And today, no matter what I tried, I couldn't get other than the blank white areas :-( :P
Summary: src path starting with a "/." causes TIFF (via QuickTime Plug-in) to show blank (USPTO patents) → src path starting with a "/." causes TIFFs (via QuickTime Plug-in) to display as blank (USPTO patents)

Comment 18

8 years ago
Two things:

1) do we have any idea whatsoever WHY Gecko is refusing to handle this (admittedly bizarre) path?

2) we really need a TE bug on the fact that this site is severely broken in Gecko browsers. (It doesn't really work in Safari on 10.6 either.)

Updated

8 years ago
Component: Plug-ins → QuickTime (Apple)
Product: Core → Plugins
QA Contact: plugins → apple-quicktime
Version: Trunk → 7.x
This is a Gecko bug, not a QuickTime bug (the site works fine in other browsers).  See comment 1, comment 3, and comment 15.
Component: QuickTime (Apple) → Plug-ins
Product: Plugins → Core
QA Contact: apple-quicktime → plugins
Version: 7.x → Trunk

Comment 20

6 years ago
I used to be able to get the patent images instantly on my old dead g4 ibook but now I can't seem to find any browser that can do it.  

Today I tried changing the "helpers" preferences in Seamonkey (and a few months ago in Firefox) to TiffViewer and Preview instead of Quicktime to view the images from the patent search pages.  No luck.  Has anyone here figured out how to get them yet?  

I have to manually copy and paste the /.tiff link from the source into the browser address - what a time waste! I'm running snow leopard now on an intel mac.

Comment 21

5 years ago
The URL in question doesn't work in any browser for me: the TIFF file returns a website error. I'm going to close this for now, please reopen if there's a current URL to reproduce.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE

Comment 22

5 years ago
bsmedberg: Yes, the decade-old IP-address-based URL from Comment 0 no longer resolves to a web page. The USPTO <http://patft.uspto.gov/> still exists, still provides patent images in TIFF and they still fail to display - at least for me on SM 2.0.14.

Here's a direct link to a TIFF which won't display for me <http://patimg2.uspto.gov/.DImg?Docid=08123677&PageNum=1&IDKey=A202AF617F39&ImgFormat=tif>. If that link won't work then search for a patent on the USPTO site and click the "Images" button on any given patent's page to load the TIFF.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
The current Quicktime Plugins i have on OS X and Windows doesn't support TIFF.
Can you check wether this page displays the image for you:
http://plugindoc.mozdev.org/testpages/tiff.html

If yes, please check what plugin handles TIFF for you, i.e. check which has image/tiff in it's mime types.
Flags: needinfo?(bugzilla)

Comment 24

5 years ago
Yes, while the USPTO TIFF images do not display, the TIFF image test page displays for me. This time tested under Windows XP with SeaMonkey 2.16.

QuickTime Plug-in 7.6.9 handles TIFF.
Flags: needinfo?(bugzilla)
Quicktime 7.6.9 on Windows doesn't handle TIFF.
OS X 10.8 comes with a newer version integrated that also doesn't support TIFF and is kept up-to-date via Software Update.
Also Apple doesn't seem to provide an official download for 7.6.9 for OS X.

Are you running an older OS X version or some manual install of Quicktime?
> Are you running an older OS X version or some manual install of Quicktime?

Nevermind, you said Windows XP. Can you please specifically check whether TIFF is listed in about:plugins in the "Quicktime Plug-in" section?
And if not, what other plugin is listing it?
Flags: needinfo?(bugzilla)

Comment 27

5 years ago
Yes, according to about:plugins on XP with SeaMonkey 2.16, QuickTime Plug-in 7.6.9 is listed as handling TIFF. When TIFF images are loading for display, the QuickTime logo is shown as a placeholder. I'm quite confident that the QuickTime Plug-in 7.6.9 is handling TIFF on XP.

FWIW, QuickTime Plug-in 7.6.4 displays TIFF on SeaMonkey 2.0.14 on Mac OS X.
Flags: needinfo?(bugzilla)
It doesn't show image/tiff support for me, so something must be different.
What exactly does the row with TIFF support show? And which DLL is it in, npqtplugin6.dll? A screenshot might help.
I added image/tiff & .tif/.tiff support to our test-plugin and that loads fine on both the plugindoc site and the uspto images, so it might just be Quicktime being confused by doing things slightly differently than other NPAPI supporting browsers.

However that still means we can't reproduce - please reopen if there is better information on reproducing this.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → INCOMPLETE
(In reply to Georg Fritzsche [:gfritzsche] from comment #29)
> I added image/tiff & .tif/.tiff support to our test-plugin and that loads
> fine on both the plugindoc site and the uspto images

Note that i can even just copy or write out images received from USPTO via NPP_StreamAsFile() and view them in an image viewer just fine.
You need to log in before you can comment on or make changes to this bug.