Last Comment Bug 433423 - MDL Chime plug-in invocation breaks after accessing specific URL
: MDL Chime plug-in invocation breaks after accessing specific URL
Status: RESOLVED INCOMPLETE
[CLOSEME 2010-11-15]
:
Product: Firefox
Classification: Client Software
Component: File Handling (show other bugs)
: unspecified
: x86 Windows 2000
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-12 16:28 PDT by Raymond Keller
Modified: 2010-11-15 10:56 PST (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Raymond Keller 2008-05-12 16:28:02 PDT
User-Agent:       Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.8.0.2) Gecko/20060416 Firefox/1.5.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

After selecting a link to download the text of a PDB (.pdb) file from the PDB website and saving the file to disk (without choosing to make this the default behavior), Firefox changes its behavior for handling locally-opened PDB files such that it now gives the "how would you like to handle this kind of file" dialog rather than invoking the MDL Chime plug-in as it used to.

Reproducible: Always

Steps to Reproduce:
Step 1: install the popular MDL Chime plug-in that the biochemistry community uses like all the time...

After attempting to download a PDB file from the PDB website (http://pdb.org/), the MDL Chime plug-in which was previously associated with viewing .pdb files is
 no longer invoked to display local .pdb files.  An example of such a download URL:

http://www.pdb.org/pdb/download/downloadFile.do?fileFormat=pdb&compression=NO&structureId=1A0Z

On selecting this URL as a link the user is prompted to (defaulted option) "open with Internet Explorer (default)", or (not selected) "save to disk".  After saving to disk, further Firefox handling of this kind of file changes, even though the "automatically perform" checkbox was not selected.  (The file was successfully saved to disk, if it matters.)

Accessing a .pdb _URL_ still results in invocation of the plug-in and successful display.  Good.

Accessing a local file is now different, however.  Either invoking Firefox and the MDL Chime plug-in via Windows Explorer association or opening the file via the Firefox File->Open File option results in a dialog asking how to handle the file.  This dialog now has "open with Internet Explorer (default)" not selected, and "save to disk" as the default.  But disk is where I got the file, and opening with IE, I think, really means use Windows's file association, which for .pdb files is Firefox, so that up pops another Firefox tab and yet another one of these dialogs.  Thus broken.
Actual Results:  
File handling for PDB (.pdb) files changed.

Expected Results:  
Not change handling.

E3Joking aside, I imagine there's a substantial userbase out there with MDL Chime and I'd love for them all to be able to use Firefox.  I'm surprised I couldn'
t find a report for this bug.  It's been around for If it's too much hassle to download the plug-in for testing (which I'm not sure is necessary to fix this bug
), email me please.

Here's what the server was sending for the download link:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=C01444B92F4A543E012F5A3DE5411E53; Path=/pdb
Content-Disposition: attachment; filename=1A0Z.pdb
Content-Type: application/download
Content-Length: 432783
Date: Mon, 12 May 2008 23:00:41 GMT
Connection: close

And here are my Windows associations for this file and type, if it's relevant at all:

C:\>assoc .pdb
.pdb=pdbFile

C:\>ftype pdbFile
pdbFile="C:\Program Files\Internet Explorer\Iexplore.exe" %1

I don't know why it says Iexplore.exe here, as executing a .pdb from command shell or Explorer still invokes Firefox.
Comment 1 Raymond Keller 2008-05-12 16:30:52 PDT
My text is a wee mangled because I had to recover it from a core, sorry.

I didn't complete saying this:  The bug has been around since at least May of last year.  I'm surprised I didn't find a report.
Comment 2 Andrew Schultz 2008-05-12 16:38:02 PDT
Content-Type: application/download
I suspect chime does not register to handle this mime type.  The server needs to deliver a mime type chime understands.  You can see the types chime handles in about:plugins
Comment 3 Raymond Keller 2008-05-12 16:49:35 PDT
It is my understanding that the server is using a type to enable the browser to _save the file locally_.  The aforementioned URL is used when a user is interested in "Download Files - PDB text".  Here is the referrring page, to give some context for the aforementioned URL:
  http://www.pdb.org/pdb/explore/explore.do?structureId=1A0Z

I imagine the Chime plug-in should not actually attempt to handle this type since the objective is to save the file locally.  Perhaps pdb.org should be using a different type -- is there a canonical "browser should save this to disk" type for file downloads?

After the user receives the download and opts to save it, local handling of .pdb files breaks.
Comment 4 Raymond Keller 2008-05-12 16:59:26 PDT
More info, if it matters:  This bug was known to users in mid-2006:

http://www.bioinformatics.org/pipermail/molvis-list/2006q3/000303.html

I think I started personally experiencing it on Jan. 28, 2007.  Maybe with my installation of 1.5.
Comment 5 Andrew Schultz 2008-05-12 18:22:32 PDT
The page has one link that delivers it as application/download and one that delivers as text/plain.  Both are not something chime understands.  See

http://www.life.uiuc.edu/crofts/bc1_in_chime/chime_talk/chimehelp2.html#Install5
Comment 6 Raymond Keller 2008-05-12 18:37:54 PDT
I am not being clear enough.  Please allow me to state the issue more simply:

Clicking http://www.pdb.org/pdb/download/downloadFile.do?fileFormat=pdb&compression=NO&structureId=1A0Z
breaks LOCAL viewing.
Comment 7 Andrew Schultz 2008-05-12 21:28:03 PDT
OK.  You might try a FF3 build to see if the problem has been fixed since 2.0:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0rc1-candidates/build1/firefox-3.0.en-US.win32.installer.exe
Comment 8 Raymond Keller 2008-05-12 22:16:47 PDT
3.0rc1 appears not to have the bug.

Wait... rc1?  Is 3 really that close?  Sweet.
Comment 9 Tyler Downer [:Tyler] 2010-10-18 12:58:11 PDT
This bug was reported using Firefox 3.0 or older, which is no longer supported. The bug has also not been changed in over 500 days and is still in UNCO.
Reporter, please retest this bug in Firefox 3.6.10 or later using a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles. If you still see this problem, please update the bug. If you no longer see the bug, please set the resolution to RESOLVED, WORKSFORME.

This is a mass search of unconfirmed bugs that have no activity on them, so if you feel a bug was marked in error, just remove the CLOSEME comment in the whiteboard within the next month.
Comment 10 Tyler Downer [:Tyler] 2010-11-15 10:56:48 PST
No reply, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.

Note You need to log in before you can comment on or make changes to this bug.