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.

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

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 ***

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!!! ].

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 ***