i am using firefox 13.0.1 as i open a file it displays html code rather than a web page
i am writing html code in a text file and then saved it as a html file. But when i open that file in firefox it displays the html code everytime i try to open the file.i have tried internet explorer also but i am facing the same problem. I am using windows 7 64-bit OS. I can't find a solution to it?
선택된 해결법
Yes, I can replicate that. If you find and replace the < followed by a space with just < then reload the page, Firefox now sees it as HTML. Apparently those spaces make a huge difference.
문맥에 따라 이 답변을 읽어주세요 👍 1모든 댓글 (17)
Are you opening it from your hard drive (address starts with file:), or from a web server (address starts with http:)?
When you view the file name in the address bar, does it end with .html, or .html.txt? (Some Windows text editors force a .txt on the end of the name and to work around this, you have to use quotation marks around the whole name in the save dialog: "myfilename.html")
Did you include the usual tags at the top of the file:
<!DOCTYPE html> <html> <head> <title>My Page Title</title> </head> <body>
Et cetera?
I am opening it from my hard drive. The file name in the address bar ends with .html not with .html.txt. I've written the following code in notepad: < !DOCTYPE html> < html> < body>
< h1>My First Heading</h1> < p>My first paragraph.</p>
< /body> < /html> Here is a screenshot of what firefox displays when i open the file.
글쓴이 rafey 수정일시
선택된 해결법
Yes, I can replicate that. If you find and replace the < followed by a space with just < then reload the page, Firefox now sees it as HTML. Apparently those spaces make a huge difference.
Hi,
I'm having a similar problem - using FF 16.0.2. Recently upgraded to windows 7, 64bit. Previously on XP, without any troubles
I have to open a link/attachment on a webpage that is a .html file.
When I click open, regardless of what software I use to do so: OpenOffice, IE, FF, notepad, wordpad - only HTML code is seen. This is what I assume to be because of what "jscher2000" mentioned - the URL is converted into a HTML.txt file.
Notably, if I go to the website on IE and open the HTML file through it, it works no problem. I have tried disabling addons.
I have been looking for fixes & addons to go around this problem, but none so far. First time posting!
글쓴이 tholius 수정일시
If there aren't any errors in the HTML code then only a wrong file extension can cause a browser to display the HTML code rather than rendering the code.
The screenshot clearly shows . txt file extension, so Firefox and possibly other browsers as well will display that file as a text file.
Removing the trailing.txt file extension should make it render properly.
How is the server sending the file?
You can check the HTTP response headers with the Live Http Headers extension.
- Live Http Headers: https://addons.mozilla.org/firefox/addon/live-http-headers/
See also:
글쓴이 cor-el 수정일시
Hello,
Thanks for your reply
Unfortunately the addon you suggested did not improve things
I have tested this on IE, and it does not have a problem opening the file as a webpage - it seems it is only FF. I can only surmise that in the process of opening, FF converts & 'saves' it to a .txt file in the temporary folder. Therefore (as I have tried already), you cannot edit/remove the .txt in the web address to just give you .html, as it is not technically a file on the computer - "file not found"
The server sends it in a puzzling/long-winded way; lines and lines of random letters/numbers: https[removed]!ut/p/c5/[removed]0MTYtQTc2MDQ1NzBGMUVGX2s5NEUwMEYyNi0wNzBFLUFDMDEtREE4Qi1ENjkzRkY0MzNFQjcvX2V2ZW50SWQvc2hvd0Rvd25sb2FkRmlsZVBhZ2U!/#
And just to elaborate, I can save the HTML page on the desktop, and open it that way without all the coding. However, it shouldn't have to resort to that.
글쓴이 tholius 수정일시
Hi tholius, judging from the crazy URL, the page is generated by a script. Usually a script that pushes a page will specify a content-type so that browsers do not have to guess. But if the site was only tested in IE, this might have been omitted because IE has a built-in feature of sniffing unknown content to determine what it is.
The Live HTTP Headers extension is useful for research to see what content-type the server is sending. Knowing this doesn't actually solve your problem, it was just to gain insight on what the server is sending. If it's sending the text/plain content-type, that would explain why Firefox is adding the .txt extension. If it is sending some other content-type, I suspect you still need a workaround.
Saving the file with a .htm or .html extension is the best workaround, but as you note, that's an extra step. I don't know whether there is an add-on that can intercede and transparently perform that step for you (i.e., bypassing Firefox's native behavior).
In your screen shot, it appears that the file opened in the browser. If you prefer to view it that way, perhaps this extension will help: https://addons.mozilla.org/en-US/firefox/addon/open-in-browser/ The screen shot suggests that you can use a new item on the view menu to change the view from plain text (HTML source) to HTML.
Firefox would usually open a file that is send as text/plain in a browser tab, so I'm not sure where you get that .txt file extension.
It is possible that the server sends the file with a MIME type that Firefox somehow associates with a .txt file extension.
The Live Http Headers extension should tell you that (is better suited for cases like this than the Web Console).
Try to delete the mimeTypes.rdf file in the Firefox Profile Folder to reset all file actions.
- http://kb.mozillazine.org/mimeTypes.rdf
- http://kb.mozillazine.org/File_types_and_download_actions#Resetting_download_actions
You can also try to clear the cache (and maybe the cookies from that site).
- Tools > Options > Advanced > Network > Cached Web Content: "Clear Now"
- https://support.mozilla.org/kb/Clear+Recent+History
Hi "jscher2000"
Thanks for your reply - it was a great idea, however it didn't work.
The error read as follows (on all options of that addon): Error 500. Request processing failed; nested exception is java.lang.IllegalargumentException: Error: Token passed as parameter not existant or empty - & variations of
What I have also noticed is that when opening the file, it states that xxx.HTML file is a text file, which makes me think that FF (incorrectly) intrinsically thinks its a .txt file?
See image below
Hi tholius, I think for the time being you have to save and open from disk. But certainly complain to the site about this problem so it can be fixed for all users.
Thanks for your help
I am decently adept at computers, but this was more of a question on behalf of some not so adept colleagues. Problematic if the items are not supposed to be saved, clutterful since the item is saved into /downloads with all the other random things, and confusing if you use FF normally, then have to switch to IE to have one or two tasks done properly
When you mention complain to the site - do you have a link, or an email to whom I raise this issue to?
Edit, "cor-el" - thank you too. I am unable to continue on with that extension as I am unfamiliar with it, & I unfortunately do not have time. I am also reluctant to delete anything in particular (although I did clear the history). I did check the applications -> file types, and it does not have a HTML execution - perhaps that is why the default is to open as a txt file? The txt execution is to ask - which coincides with what has been happening. Regards
글쓴이 tholius 수정일시
Hi tholius,
When you mention complain to the site - do you have a link, or an email to whom I raise this issue to?
I meant the site that is hosting the download. I think you blacked that out in your image, so I'm not sure what to suggest.
I'm still not sure that this isn't a problem on your side and not a problem with the server.
Can you try to delete the mimeTypes.rdf file in the Firefox Profile Folder to reset all file actions.
You can use this button to go to the Firefox profile folder:
- Help > Troubleshooting Information > Profile Directory: Show Folder
Hi "cor-el" - I have tried deleting the mimetypes.rdf file (3 times in fact) to no avail. When FF opens the HTML, it still states "...which is a .txt file" and webcode comes about.
Regardless, my colleagues are becoming accustomed to IE to open HTML files at the moment - a temporary measure until this problem is solved, hopefully in the future versions of FF!
Hi tholius, Firefox has behaved this same way forever, and I do not think it will be changed. If the server specifies that it is sending a plain text file, Firefox will treat it as such. Unless there is an add-on to correct for the erroneous information sent by the server, the only solution is for the server side to be fixed (or to use the workaround of saving the file with a correct extension).
Hey "jscher2000" - if the server were sending it as a plain text file - wouldn't that mean that IE would have the same difficulties? Also, when I save the file, I do not need to change any extension, it automatically saves as a HTML file, which can be opened (correctly & without webcode) by double clicking. You are right though, hopefully some genius can make an addon then! The server is unlikely to change though (although I will ask) - it's from government - for them HTML is like 5kb on their server - any other file time would probably tend to be unnecessarily bulky!
PS. I tried to GC, unfortunately that just automatically saves the file onto HD (unwanted), doubling clicking and opens perfectly.
글쓴이 tholius 수정일시
Hi tholius, I don't know why choosing Save rather than Open would result in a different file extension.
IE does not rely completely on the content-type sent by the server, and instead inspects the beginning of the file. It's one of many little conveniences developers come to rely on...
Depending on the scripting language, the change might be as simple as one of these:
Classic ASP:
Response.ContentType = "text/html"
PHP:
header("Content-type: text/html");
Or the server default for unrecognized file extensions could be changed from text/plain to text/html.
Still, I tend to agree that government sites may have a slower change process than commercial sites.