Closed Bug 249153 Opened 21 years ago Closed 20 years ago

XML documents presented as plain text after 0.9

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 259206

People

(Reporter: romayev, Assigned: bugs)

References

(Depends on 1 open bug)

Details

(Whiteboard: skip to comment 13)

Attachments

(1 file)

Firefox Mime Handling Debug-Analysis
2.87 KB, application/x-gzip
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 Since 0.9 the browser displays XML documents without XML tags, just as plain text. Reproducible: Always Steps to Reproduce: 1. Open an XML document in the browser window 2. 3.
Can you provide us with a sample URL where you're seeing this?
WFM windows firefox 0.9.1 please install firefox on a clean folder with a new profile and no extension
(In reply to comment #0) > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 > Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 > > Since 0.9 the browser displays XML documents without XML tags, just as plain text. > > Reproducible: Always > Steps to Reproduce: > 1. Open an XML document in the browser window > 2. > 3. I've removed all installations of the browser using Add/Remove programs in control panel, rebooted the computer and installed the lastest version. Still the same problem. I'm not sure what you mean by clean profile and no extention, though.
If you go to Start | Run and enter %APPDATA% , you'll be taken to your Application Data folder. In there there will be a folder called Mozilla. In there a folder called Firefox. The Firefox folder contains your profile. If you rename or delete it, Firefox will create a new profile. Can you test with a new profile? Bear in mind that your bookmarks and personal settings are stored in the profile, so you may want to save a copy of your bookmarks.html.
Marking this as worksforme. I've tested on recent Win32/Linux builds. Please only reopen if you can definitively reproduce using a build with a clean profile as I described. Please also specific what version of Firefox you're using to test if you need to report back again.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
- Removed Mozilla directory from %APPDATA% - Removed Firefox using add/removed programs - Restarted computer - Installed Firefox version 0.92 still the same problem. No XML tags are being displayed, just flat text inside the tags.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
This is also broken for me. I'm using the recent Debian package of 0.9.1. All xml documents (regardless of content) are rendered as plain text, whether served from a remote site, or from the local machine through a file:// URL. Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040712 Firefox/0.9.1
Also does not work with Seamonkey Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040707 Debian/1.7-5 I tried both with completely fresh profiles (created new user, who ran mozilla and firefox for the first time) and with remote and local xml files, including a very simple test case: <?xml version="1.0" encoding="ISO-8859-1"?> <block> <element> Something </element> </block> In all cases, Page Info indicated the page mime type was text/xml and rendering was standards compliance mode. No errors were seen when run from the command line. I don't have any more information, but I can confirm that I'm experiencing the same bug.
Same with Firefox 0.9.1 on Gentoo Linux Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040725 Firefox/0.9.1 and Mozilla 1.7 on Gentoo Linux Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040725 and Ephiphany 1.26 on Gentoo Linux based on the Mozilla 1.7 GRE (see above) ++ an additional Problem: XSLT-Transforms do not (no longer) work, when XML and XSL-File are both locally stored: "Error loading stylesheet: (null)" (No-Problem when loading same docs from an (apache) web server) Obviously the problem is in GRE itself. Maybe wrong "content type guessing" / "mime type detection". Axel P. S.: Vote for this bug! :-)
Alex, I think this bug can be regarded "as confirmed". But I can't change the bug status... Axel
... I finally found the reason! (On gentoo linux, gnome 2.6, mozilla/firefox 1.7/0.9.1) It depends on the MIME-TYPE that firefox/mozilla detects for XSL-Files! If an XSL Stylesheet/Transform is not detected as "text/xml" it is not applied or rather not loaded into the browser. ( mozilla/content/xml/document/src/nsXMLPrettyPrinter.cpp: PrettyPrint(): rv = loader->LoadLocalDocument(channel, nsnull, getter_AddRefs(xslDocument)); => -1 ) Try to open a local (file://) XSL-File in the browser. If you are prompted for an external application, you are affected because "PrettyPrint" uses (loads) "chrome://communicator/content/xml/XMLPrettyPrint.xsl" internally as an XSL Transform. This has two consequences: 1. Local (file://) XML-Files are not automatically "PrettyPrinted" 2. Local XML-Files with a local XSL-Transform yield an error. I don't know, why this happens now, i. e. with current versions of mozilla/firefox. Maybe MIME-Type detection has changed. (http://www.mozilla.org/docs/web-developer/mimetypes.html) But obviously in this case (at least on my gentoo/gnome desktop) mozilla does NOT detect the MIME-Type by itself... ... it uses the operating system / environment to determine it. (I haven't debugged the corresponding code, yet) It took me some time to find out, which sources are actually used in Gnome 2.6 (or rather mozilla) to determine mime-types. - /etc/gnome-vfs-mime-magic ??? - ${prefix}/share/mime-info: *.mime / *.keys ??? - ${HOME}/.gnome/mime-info: user.mime / user.keys ??? - ${prefix}/share/mime/packages/freedesktop.org.xml ??? (with ${prefix} == "/usr", "/usr/local", ... depending on your installation) I changed ALL of the above dirs/files (finally "freedesktop.org.xml) to force XSL Files to be detected as "text/xml", but I am quite sure that "freedesktop.org.xml" (from "shared-mime-info" package) was crucial. Details: - /etc/gnome-vfs-mime-magic: INSERT LINE 0:256 string \<xsl:stylesheet text/xml after 0:64 string \<?xml text/xml - ${prefix}/share/mime-info: gnome.mime && gnome-vfs.mime Add "xsl" to the extension list of "text/xml", i. e. text/xml ext: xml xsl - ${HOME}/.gnome/mime-info: user.mime / user.keys Remove every entry that might be "xsl"-related. - ${prefix}/share/mime/packages/freedesktop.org.xml: COMMENT the original entry for mime-type "text/x-xslt" <!-- <mime-type type="text/x-xslt"> <comment>XSLT stylesheet</comment> <comment xml:lang="no">XSLT-stilark</comment> <glob pattern="*.xslt" /> <glob pattern="*.xsl" /> </mime-type> --> ADD pattern "*.xsl" to entry for mime-type "text/xml" <mime-type type="text/x-xslt"> ... <glob pattern="*.xml" /> <glob pattern="*.xsl" /> ... </mime-type> and RUN "update-mime-database ${prefix}/share/mime" Now restart your Gnome Desktop and open "nautilus" to verify that the MIME-Type for XSL-Files is now "text/xml" or rather "XML document". (You might have noticed already that "nautilus" uses at least two ways for MIME-Type detection: Initial directory display and after selecting a file) And NOW... Open a local (file://) XML-File with mozilla/firefox (1.7/0.9.1). :-) BytheWay: It might be possible to reproduce the same problem on Win32-Systems, by modifying/creating HKCR\CLASSES\.xsl. Hope that this information might help others (feedback welcome). Axel
In my case, if I access an XML (or XSD) file via a URL it displays as plain text. If I access it using File->Open it treats it as XML and does all the syntax highlighting This is on Windows XP Pro using the latest nightly build.
In reply to comment #14: What do you mean by "access via a URL"? Assuming that you are referencing the same document using an web-server (IIS, Apache, ...), i. e. "http://..." and not "file://...". If so, the "content-type" that the server sends determines how mozille/firefox handles the document. "View Page Info" in context menu (web developer extension) will show the preceived "Type" and "Render Mode". If it is NOT "text/xml" but "text/html", the server is sending the wrong content type for your XML-document. For local access (file://...) seems to work on your system, I would like not know, what mime-type is associated for .XML and .XSL files. Could you check the corresponding HKCR-Entries in your registry? Greets Axel
Let me clarify: If I access an XSD via a webserver, using an http:// prefix, it displays as plain text. If I view the page info, it shows the type as text/plain and using Quirks render mode. If I access the same XSD using the File->Open File option in Firefox, it treats it as being XML, type of text/xml and uses standards compliance mode. My HKCR settings for XSD has Content Type set to text/xml, PerceivedType to text With Internet Explorer it shows as xml in both cases.
I can also confirm - using Firefox 0.9.1 under Fedora Core 2. I see it on both local and remote xml files - with page-info showing a text/xml mime type. If I open an XSLT file directly, page-info indicates a "text/x-xslt" mime-type (I would have thought it should be 'application/xslt+xml' if anything). I hesitate to alter the operating systems default mime-type for this, as per Axel's suggestion, as I don't know what other repercussions that could have.
Browsing the history of the corresponding W3C-documents is quite interesting! * As of version 1.0 the "official/recommended" media-types for XSL files were "text/xml" or "application/xml" (http://www.w3.org/TR/xslt) -- begin quote -------------------------------------------------------------- The MIME media types text/xml and application/xml [RFC2376] should be used for XSLT stylesheets. It is possible that a media type will be registered specifically for XSLT stylesheets; if and when it is, that media type may also be used. ---------------------------------------------------------------- end quote -- * The corresponding "official recommendation" for XSLT 2.0 was defined during the development of the 2.0 Draft and is now "application/xslt+xml". (Definitely not "text/xslt", "text/x-xslt", ...) See "http://www.w3.org/TR/xslt20/#media-type-registration" and have also a look at previous releases to see how things evolved. My personal opinion is that "mozilla is very standard compliant". This is one reason among others why i like mozilla or rather the mozilla products. So why not change the operating system setting, if it goes wrong. :-) Axel
I think bug 155730 is the real problem now. text/xml is WRONG for XSLT, and I don't want to do it. Axel, using your adivce, I convinced Gnome-VFS that .xslt files are application/xslt+xml - at least until it's brainded content sniffer tries to tell me they are text/xml, because of the XSLT file's <?xml header. That whole mess led me to bump into you over at http://bugzilla.gnome.org/show_bug.cgi?id=138359 as well. Lets hope the new Mime stuff in Gnome 2.6 ( http://freedesktop.org/Standards/shared-mime-info-spec ) will let us fix this.
'application/xslt+xml' is not a registered MIME type. It should be 'application/xml' (not 'text/xml' which is in process of being deprecated and has a couple of flaws). I would suggest to not change to 'application/xslt+xml' until XSLT 2.0 reached recommendation.
URL: http://www.sec.gov/Archives/edgar/dat...
Depends on: */*+xml
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: skip to comment 13
I have attached the Analysis of my firefox/mime Debug-Session and my "gdbinit" that includes some useful macros for debugging mozilla mime ("brkmime" sets breakpoints for tracing mozilla mime-handling of local XML/XSL-URLs. "prun", "ps", "pu" are taken from the official mozilla unix debug page). Furthermore the following mozilla URLS give an overview of how mime is handled in mozilla: - http://www.mozilla.org/docs/web-developer/mimetypes.html - http://www.mozilla.org/catalog/libraries/uriloader/helper-app-techtalk.html I think that most (if not all) questions that are relevant for this bug have got an answer and that a (mozilla) fix is NOT required. (Though - as Chris pointed out - our discussion IS RELEVANT for current (and future) releases of GNOME and/or "shared-mime-info" Summary (my view): 1. The discussion about MIME-Types "application/*+xml" should be continued in bug #155730. For these MIME-Types are not defined for XSLT 1.0 (introduced during development of 2.0) they are more relevant for future than for current releases of mozilla. 2. Unexpected "display behaviour" of XML-Files that are loaded from a web-server (http://) should be fixed ON THE SERVER, i. e. by sending the appropriate content-type: "text/xml". 3. Misbehaviour for local XML/XSL Files (file://) - displayed as "plain text" (also when loaded from a webserver, because PrettyPrint XSL is loaded locally) - error message when applying XSL-Transforms that happens because of a wrong local mime configuration should be solved by fixing the local configuration using one of the following ways (not ordered by preference): a.) Delete ALL mime mappings for extension ".xsl". This will force mozilla to inspect its "Extra Mime Entries" and to find { TEXT_XML, "xml,xsl,xbl", ... } b.) Set you OS-provided mime mapping for extension ".xsl" to "text/xml". * Windows built: CLASSES_ROOT\.xsl (USER and or MACHINE) * Unix build (with or without GTK+2): - ~/.mime.type && ~/.mailcap (user) - /etc/mime.types && /etc/mailcap (system) * Unix build with GNOME/GTK+2: - ${prefix}/share/mime/packages/freedesktop.org.xml (requires "update-mime-database ${prefix}/share/mime") - ${prefix}/share/mime-info/gnome-vfs.keys (requires restart of "gconfd-2") "My way" is to change the the GNOME/GTK+2 setting as I have already pointed out (Warning: There is a typo in my instruction for editing "freedesktop.org.xml". The inserted section should define "text/xml" and not "text/x-xslt" again :-)) BytheWay: Adding/introducing "xsl" => "application/xml" (in freedesktop.org.xml) and "application/xml" => "XSL application (XSLT)" (in gnome-vfs.keys) also works, because mozilla "listens" to this content-type, too. (@Anne: What is your source for "text/xml is in process of being deprecated"?) The corresponding "example sections" are: == freedesktop.org.xml == <mime-type type="application/xml"> <comment>XML application (XSLT)</comment> <magic priority="51"> <match offset="0:256" type="string" value="&lt;xsl:stylesheet" /> </magic> <glob pattern="*.xsl" /> <glob pattern="*.xslt" /> </mime-type> == gnome-vfs.keys == text/x-xslt description=XML Application (XSLT) category=Documents/Extended Markup Language (XML) default_application_id=firefox ===================================================================== Specifying a "default_application" (mozilla: "handler") is REQUIRED! Greets, Axel
A typo again... == gnome-vfs.keys == application/xml description=XML Application (XSLT) ... NOT == gnome-vfs.keys == text/x-xslt description=XML Application (XSLT) ... Sorry, Axel
Please don't recommend people to use 'text/xml', it has serious problems (especially with character encoding). 'application/xml' wasn't created for nothing. > Major changes from RFC 3023 are as follows: > First, text/xml and text/xml-external-parsed-entity are deprecated. <http://lists.w3.org/Archives/Public/www-html/2004Jul/0004.html> Should this bug be marked INVALID by the way? Since it was, after all, an invalid bug report.
Anne, thank you for "the source". I did not know that RFC3023 will be superseded by this RFC... Obviously it is quite difficult to stay up2date with changing standards. Otherwise "mozilla" would not map ".xml", ".xsl" and ".xbl" to "text/xml" as last resort, "freedesktop.org" would not have introduced "text/x-xslt" and I would not have recommended "text/xml"... Sorry for that. Following your or rather the new RFC's information I will switch to "application/xml" (by changing GNOME/shared-mime-info and/or web-server configuration appropriately) ... ...at least for the moment (until application/*+xml becomes a registered mime-type). :-) I agree, this bug can be closed. Though I do not think that it is an "INVALID bug report". Obviously mime-types and content-type handlers are "mine-fields". Consequently users and/or "managed desktop"-providers will get into trouble. When searching BugZilla they will now (and in the future, if CLOSED Bugs are included in the search) find information that might help them out. Axel
Ok, I caved and mapped .xsl and .xslt to text/xml. Firefox now displays XML as a tree. However, Evolution crashes when I try to add an XML or XSLT attachment :( Anyone else see this, or did I mess something up? Time to switch over to the Gnome bugzilla I think :P
I filed a bug on my Evolution problem here: http://bugzilla.ximian.com/show_bug.cgi?id=64405
Chris, please read comment 23 and comment 24.
Anne, where are you getting to? Do you really think that Chris hasn't read our comments about "application/xml" and "text/xml"? More than one focus or role is allowed: - Just fix a strange behavior that is currently annoying me (and keep in mind that things are changing, i. e. "application/*+xml") - Confirm that a published workaround solves a problem - Find and publish a workaround for a known problem - Inform about upcoming changes of standards - Take part in the process of (re-)defining a standard, i. e. write or contribute to an RFC, etc. - Write standard compliant software or update the software to keep it standard compliant - ... There are many ways to profite from or to contribute to the "Open Source Community". Axel
Maybe related to/duplicate of bug 259206 and/or bug 258776?
*** This bug has been marked as a duplicate of 259206 ***
Status: NEW → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: