313293 - Does not load a PHP file correctly when offline. Bug# 244257 may have solved it.

Status: RESOLVED DUPLICATE of bug 244257

(Firefox :: Settings UI, defect)

Description

[Parkhideh]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; CDonDemand-Dom)
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax; CDonDemand-Dom)

When online a file with php extension (that is html with <script language="php">
) works fine.
When offline I expected the browser to show the html portion and ignore the
<script ...> section.  No such luck.  It looked in WINDOWS association and
started the associated PHP application.
This is an OFFLINE problem with FireFox 1.5.
Renaming the extension PHP to HTM fixed the problem; showing FireFox does ignore
the script correctly.  
Next I tried to associate PHP with FireFox (in FireFox and not Windows) and I
ran into what is reported by Bug# 244257.
For developing and trying webpages offline; this is a serious shortcoming.



Reproducible: Always

Steps to Reproduce:
1.Create an A.html file that calls two  html files in two frames, say B.html and
C.html.
2.Rename C.html to C.PHP and change A.html to call C.PHP
3.Make sure that windows has no association with PHP extensions.


Actual Results:  
The association window of OS pops up.  Netscape 7.1 with Mozilla/5.0 has no such
issue.  Nor has FireFox when calling the PHP file ONLINE from a remote HOST.


Expected Results:  
PHP extension should be treated as HTML when OFFLINE.
I consider this (if verified) a major deficiency for offline users (developers).


Whether important or not.  When FireFox 1.5 beta is checked OFFLINE, it still
reaches the host.  That caused some confusion too.  So the message OFFLINE only
shows up if reaching the host fails AND Work Offline is checked.

Comment 1

[Robert Strong (they/them - no direct email)]

Extension / Theme manager as in addons and not file extensions. Changing
component to same as bug 244257.

Comment 2

[Elmar Ludwig]

This has nothing to do with being online or offline: The PHP is interpreted on
the web server and its output (typically HTML) is then sent to the browser, so
the browser never actually sees the PHP file on the server. If the server would
transmit the PHP file itself, Firefox would handle it in the same way as it does
when dealing with local files.

What you ask for (adding an easy way to associate PHP files with Firefox) has
been WONTFIX'ed in bug 244257 already, and I see no reason why this bug is not
a duplicate of that bug. -> Marking as such.

*** This bug has been marked as a duplicate of 244257 ***

Comment 3

[Parkhideh]

In order to demonstrate the issue of ONLINE vs OFFLINE behavior; I have created five files  as shown below.  Four of the files, a.txt, a.php, a.html and a.abc, are identical html files with one line of PHP script and one line of html.  The fifth file is a.bcd which is a renamed JPG file.  The links are:
http://farmansara.home.att.net/a.txt
http://farmansara.home.att.net/a.php
http://farmansara.home.att.net/a.html
http://farmansara.home.att.net/a.abc
http://farmansara.home.att.net/a.bcd             (a jpg file)
[att.net was chosen because PHP processor is not enabled]

Now I looked at FireFox 1.5 in all cases Online and Offline.  Based on explanation offered for PHP, in each case I looked at "View Page Info" and this is my conclusion:

1a- FireFox 1.5 Online seems to assume all files are Type: text/plain unless it recognizes their extension.  It displays .txt, .php and .abc as text files within the browser.
1b- FireFox 1.5 Offline seems to refer odd extensions like .txt, .php and .abc to PC's application finder "Open with ...".
*** This behavior is inconsistent for I expected them to open as embedded Type: text/plain files in offline mode too ***

2- The last file a.bcd has somewhat a different pattern:
3b- FireFox 1.5 asked for which plugin to use when online.
3c- FireFox 1.5 offline acted similar to its last behavior mentioned in 1b.
*** Again 3b and 3c is not consistent *** (I admit not knowing how to provide it with a jpeg plugin yet :)  )

Side note:
[Mozilla/Netscape 7.1 when online opens all non .html as "type: text/plain" ; 
and when offline it assumed .php and .abc to be Type: text/html, with .bcd as Type: image/jpeg   somehow!!!   ].

Comment 4

[Elmar Ludwig]

I'm not sure what you are trying to "prove" here...

Regarding your observations:

1a)
Firefox does _not_ do content type guessing here. The HTTP server is sending
the content type "text/plain", so Firefox is displaying the content as text.
You can easily see this by looking at the server headers in Web-Sniffer, e.g:
<http://web-sniffer.net/?url=http%3A%2F%2Ffarmansara.home.att.net%2Fa.abc>

1b)
Firefox has absolutely nothing to do with what you see. The Windows Explorer
application maintains a list of registered file types and shows the dialog you
mention for unrecognized file types. If you _want_ to open these in Firefox,
you have to tell the Explorer to do so (by associating these file types with
the Firefox application _in Windows Explorer_), otherwise Firefox will not
even notice that you try to open them.

3a)
What you see here is that the HTTP server sends a binary file with the type
"text/plain" (see above), but Firefox refuses to believe this and will offer
to e.g. save the file for you instead (since displaying random binary content
in the browser window is not useful at all). This might be considered as odd
behaviour, but is intentional, see bug 290800. In particular, Firefox does not
know and will not guess what the file type really should be.

3b) see 1b), nothing to do with Firefox

So, what you ask for is essentially to associate extensions like ".php" with
Firefox.exe in the Windows Explorer. And this is exactly what bug 244257 (and
bug 216501) is about. Just because you can reopen a bug does not mean that you
should if you disagree, Bugzilla isn't a democracy. If you want to argue, take
it to private email.

*** This bug has been marked as a duplicate of 244257 ***