274930 - Links with .PHP extension screw up and disable "Save As..." dialog box.

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[Justin]

Whenever a .PHP file link is clicked, Mozilla can no longer display the Windows
Common Dialog "Save As..." dialog box.

This error happens after the link is clicked as a normal browsing operation (ie.
left-click, or right-click and Open In New Window / Open In New Tab).  If the
link is NOT clicked as a "browsing" operation (ie. if the link is right-clicked
and "Save Link Target As..." is selected), the contents can be saved just fine.

This error continues to remain in effect for anything that requires the "Save
As..." dialog, including right-clicking images to save them, saving other pages,
even saving the output of the .PHP script if the HTTP headers dictate an
"attachment" Content-Disposition or the MIME Content-Type does not match
something Mozilla can display inline.  (note that the window asking if the user
should save it, open it with default application, or open with another
application still pops up).  After this error has occurred, it spans to
everything in the Mozilla suite, including trying to save pages created with
Composer!!!  (THIS IS CRITICAL, as oviously if one started creating a page, did
not save it, and then this error occurred, they have no way of saving the page,
short of going to the HTML code view, copying all the text to the system
clipboard, and then pasting it into Notepad or another text editor and saving it
that way!)

The only way to clear the error condition is to completely unload Mozilla.  (ie.
close all windows, including Composer, Mail & Newsgroups, Address Book, and
anything else in the Mozilla suite)

This bug is present in Mozilla version 1.7 and continues to be present in
version 1.8.

This bug has not been tested on links with other file extensions, or operating
systems other than Windows 95 and Windows 98.

Comment 1

[Hermann Schwab]

I can test using Win98 and Win98SE, but I don´t want to look for an URL where
that happens. Can you tell an URL?

Version 1.8 doesn´t exist yet, there are milestones, latest is 1.8a5.
There are nightlies, new each day with some bugs fixed or created ;-)
currently I´m using yesterdays nightly:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a6) Gecko/20041215

As bugs are getting fixed each day, it would be nice to know the lkatest version
of mozilla you have seen this bug.
Was it 1.8a5 release, or a nightly some days before or after?
Please open Help->About Mozilla, or just type about: into the location bar, and
copy and paste the string telling about mozillas properties:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a6) Gecko/20041215
You can see it is win98, but don´t know if 98 or 98SE, 
you can see it is a 1.8 nightly, as 1.8a6 isn´t released yet,
and you can see it was build Dec 15th, 2004.
Branch nightlies would have the same date, but a rv:1.7.5 instead.of 1.8a6
 
I´m pretty sure I don´t see the bug on my current nightly, but maybe I see it on
the build you specified?
Are you creating phps, or just surfing?
Is there a difference loading phps from your local server or from the internet?

 

Comment 2

[Justin]

Good point.  This happened while I was doing local PHP development (running a
small web server on localhost).  I uploaded the same simple PHP test script to a
remote web server, and the error didn't happen!  I examined the HTTP headers,
and noticed there are some slight differences.
-----------------Headers from localhost server:
HTTP/1.1 200 Ok
Server: Xitami
Date: Fri, 17 Dec 2004 07:01:10 GMT
Cache-control: no-cache
Expires: 0
Content-length: 12
Cache-control: no-cache; must-revalidate
Expires: 0
Pragma: no-cache
Content-type: text/plain; charset=US-ASCII
X-powered-by: PHP/4.3.9
-----------------Headers from remote server:
HTTP/1.0 200 Ok
Content-Length: 12
Cache-Control: no-cache; must-revalidate
Expires: 0
Pragma: no-cache
Content-Type: text/plain; charset=US-ASCII
X-Powered-By: PHP/4.3.3
Server: Xitami
-----------------
Note that the remote server is running Xitami 2.4d9 /Win32 and only supports
HTTP/1.0
My localhost server is Xitami 2.5c2 /Win32 and it supports HTTP/1.1

Perhaps the HTTP version differences could be causing the problem?  Or maybe
it's just the way Mozilla is handling "http://localhost/" in it's URL box?

If you're curious, the URL for the test file on the remote web server (which
doesn't seem to cause the problem) is:

http://cyberpimp.pimpdomain.com/usr/administrator/world.php

(The cyberpimp server is VERY SLOW...  give it 30-45 seconds to run the script.
 And don't worry, there's no adult content.  It's just a domain name. ;-))

If you would like to see the source code (it's quite simple ;-)), it can be
found at:

http://cyberpimp.pimpdomain.com/usr/administrator/world.php.txt


There is one more thing I discovered tonight which seems to be linked to this
same bug: When the "Save As..." dialog box is no longer functioning, the
"Print..." dialog box also dies and instead an error dialog pops up!  Only the
error dialog box has no text... just the yellow triangle + exclamation mark icon.

Oh yeah, before I forget...  the version I have is 1.8a5.  (Mozilla/5.0
(Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041122)  Just downloaded it after
this dialog box error bugged me (no pun intended) with 1.7.  Unfortunately the
bug is still here.  :-/

Comment 3

[Justin]

Oops I almost forgot: I'm running Windows 98SE, with the Windows 95 shell. 
(This was done with the "98 Lite 4.5" custom installer.  http://www.litepc.com/ )

Comment 4

[Boris Zbarsky [:bzbarsky]]

Justin, please open the JS console before clicking on the link that causes the
problem.  Are there any errors in the JS console?

Comment 5

[Matthias Versen [:Matti]]

no response