User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040416 Firefox/0.8.0+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040416 Firefox/0.8.0+ Summary: I understand that in handling files Firefox checks the MIME type sent by the server (which is to be expected, of course), and that if the MIME type is not recognized, and it isn’t in some manner of pre-configured list of types to render regardless (e.g. JPG, GIF, HTML), the program gives you two choices: 1) save to disc, 2) open with default application. Problem: I use Macromedia Dreamweaver to develop Web pages in various Internet languages including PHP. When I try to preview in Firefox, something that is quite important for developers trying to make sure their sites are fully supported in Mozilla and company without extra stress, I am presented with the dialogue box and given no option to view the file. Solution: Given the nature of this issue I would like to propose that PHP (along with other obvious Internet languages like ASP perhaps if they are not included) be added to the list of file types to render whenever Firefox encounters them even without a proper MIME type. This would allow people who code their sites in various tools that have preview options to use Firefox (and perhaps Mozilla too) in previewing these files. Problems: I don’t see any myself. Some might wonder if this would ever lead to problems, but I can’t imagine why. Can you really think of many cases in which a PHP file being sent to Firefox/Mozilla would be for anything other than the program actually rendering them? I suspect this might also have something to do with many download scripts on the Internet failing as well. I realize that local PHP script will contain elements Firefox won’t be able to render, but given the circumstances under which this will take place I definitely think a change should be made. And if the later is involved (download scripts not working) it would be a change that would improve usability for people who aren’t geeks—the sort that don’t like to use browsers that put them in cryptic unexpected situations. Also, if denied, it would be very wonderful if some configuration or preference option (even in about:config) could be added for geeks like Web designers who would like to see this functionality, making FireFox and company work as expected and also making it easier to develop for these browsers. Additional suggestion: The dialogue box presented in this situation should be given a third option; “Open with FireFox,” just in case the person using the browser wants to do just that. This might help to ease problems for file types that the user might not actually want to preview in Mozilla. Reproducible: Always Steps to Reproduce: 1. Create PHP file in Dreamweaver 2. Attempt to preview in FireFox. Actual Results: Presented with a dialogue asking if I wish to 1) save to disc, or 2) open with 'default application' (which ironically is the very one I sent the preview from). Expected Results: FireFox should have rendered the file. If not that, the dialogue box should certainly have offered an option to open with FireFox (and while this would be a good feature to add, in my opinion, it doesn’t truly solve the concern above given the annoyance of dealing with the extra step).
Since you're using Mac OS X, a better way to resolve this problem is just to start web sharing, enable PHP, save your Dreamweaver PHP file to your web documents and then preview it in your browser like that. It makes a whole lot more sense. Anyone else think this bug is invalid?
It is possible to do this in Firefox currently. In the location bar type about:config and press enter. Search for network.http.accept.default You can add your PHP mime type from there and you may have to restart Firefox. I'm marking this as invalid since Firefox should only accept what it can render. While it could render a PHP file, none of the PHP would be parsed of course. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041002 Firefox/0.10
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.