1204553 - xml:space="preserve" isn’t respected in the no-style-information "document tree" presentation of an XML document

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Emmanuel Gil Peyrot]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20150914030205

Steps to reproduce:

Open data:text/xml,<test xml:preserve="space">test    test</test>


Actual results:

The four space characters are only displayed as one space.


Expected results:

There should be four spaces in the source view.

This is especially important for embedded source code where indent is important and new lines essential for reading.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Emmanuel Gil Peyrot from comment #0)
> Expected results:
> 
> There should be four spaces in the source view.

What do you mean by "source view"? If I do view-source (ctrl-U) on that page, I do see 4 spaces.

If I just directly view your URL, the browser (both Firefox & Chrome) displays a header which says:
"This XML file does not appear to have any style information associated with it. The document tree is shown below."

So Firefox is just showing a representation of the DOM -- not a styled version of the document. Can you provide links for why you think "xml:preserve" should be honored in our unstyled rendering of the XML?

> This is especially important for embedded source code where indent is important and new lines essential for reading.

(Note that you can also use "<pre>" in HTML for this, and/or the CSS that it's built upon, e.g. the "white-space" property.  Though none of that will work in an unstyled XML document.)

Comment 2

[Emmanuel Gil Peyrot]

This bug is about that unstyled document tree, which should still honor the XML space preservation attribute.

Here is an actual document exhibiting this issue: https://www.khronos.org/registry/webgl/extensions/OES_vertex_array_object/extension.xml

Comment 3

[Daniel Holbert [:dholbert]]

For reference, do any other web browsers render that document in the way that you expect?

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Emmanuel Gil Peyrot from comment #2)
> This bug is about that unstyled document tree, which should still honor the
> XML space preservation attribute.

(My understanding of the "The document tree is shown below" top-of-the-page disclaimer is that it means we are *only* dumping a simple serialization of the DOM, and we're explicitly not doing any particular type of styling.)

Comment 5

[Daniel Holbert [:dholbert]]

(It would help if you (1) could provide a link to some definitive documentation on what this attribute is expected to do, and (2) explain why you think that should apply to the raw dump-of-the-DOM view.)

(Side note: I think your data URI may have a typo -- it uses "xml:preserve", vs. you used "xml:space" in the bug title, and the khronos URL uses "xml:space" as well.)

Comment 6

[Emmanuel Gil Peyrot]

(In reply to Daniel Holbert [:dholbert] from comment #3)
> For reference, do any other web browsers render that document in the way
> that you expect?

I just tried both Epiphany (a webkit2gtk browser) and Chromium, none of them is honoring the xml:space="preserve" attribute either, and I don’t have access to any other web engine.

(In reply to Daniel Holbert [:dholbert] from comment #4)
> (In reply to Emmanuel Gil Peyrot from comment #2)
> > This bug is about that unstyled document tree, which should still honor the
> > XML space preservation attribute.
> 
> (My understanding of the "The document tree is shown below" top-of-the-page
> disclaimer is that it means we are *only* dumping a simple serialization of
> the DOM, and we're explicitly not doing any particular type of styling.)

This is an XML feature, so it would make sense to support it I think, even without any explicit stylesheet associated (there are three stylesheets loaded from chrome:// on that kind of document, which would be the place where this bug would be fixed, you can see them in F12 > Style Editor).

(In reply to Daniel Holbert [:dholbert] from comment #5)
> (It would help if you (1) could provide a link to some definitive
> documentation on what this attribute is expected to do, and (2) explain why
> you think that should apply to the raw dump-of-the-DOM view.)

The XML specification itself defines this attribute, and is quite explicit in that “the value "preserve" indicates the intent that applications preserve all the white space”, source: http://www.w3.org/TR/xml/#sec-white-space

> 
> (Side note: I think your data URI may have a typo -- it uses "xml:preserve",
> vs. you used "xml:space" in the bug title, and the khronos URL uses
> "xml:space" as well.)

Oops, I hadn’t noticed that, thanks.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Emmanuel Gil Peyrot from comment #6)
> The XML specification itself defines this attribute, and is quite explicit
> in that “the value "preserve" indicates the intent that applications
> preserve all the white space”, source:
> http://www.w3.org/TR/xml/#sec-white-space

Note that that section of spec also says:
> In valid documents, this attribute, like any other, MUST be declared if it is used.

...and "declared" is a link to the section that talks about "ATTLIST", which is what you're expected to use to declare  attributes and say what values are valid.  So, your data URI and the khronos xml document are both in violation of that section of the spec, which may be part of what's causing trouble here.

If you used an ATTLIST (and a DTD which I think is where the ATTLIST would appear), then it's conceivable that this might work -- or at least, I'd see more justification for the expectation that it'd work [based on the spec].

For right now, though, things seem to be working as-expected. The spec describes this attribute, and says it must be declared before it's used. So, documents that do not declare it should not expect any particular special handling for it.

Comment 8

[Emmanuel Gil Peyrot]

(In reply to Daniel Holbert [:dholbert] from comment #7)
> ...and "declared" is a link to the section that talks about "ATTLIST", which
> is what you're expected to use to declare  attributes and say what values
> are valid.  So, your data URI and the khronos xml document are both in
> violation of that section of the spec, which may be part of what's causing
> trouble here.

Indeed, I overlooked this part (and always used and seen used xml:space without even a specific DTD, either in SVG or in HTML5, or like here in style-less documents).

> 
> If you used an ATTLIST (and a DTD which I think is where the ATTLIST would
> appear), then it's conceivable that this might work -- or at least, I'd see
> more justification for the expectation that it'd work [based on the spec].
> 
> For right now, though, things seem to be working as-expected. The spec
> describes this attribute, and says it must be declared before it's used. So,
> documents that do not declare it should not expect any particular special
> handling for it.

It still doesn’t work though, in all three browsers I tested this on, when the attribute is explicitly declared.

I’d argue for this attribute to be supported even when it isn’t declared, based on widespread usage, but I’d be fine with only having it working when it is declared, as per the specification. :)

Comment 9

[Daniel Holbert [:dholbert]]

To be clear, "view-source:" in the bug-summary here is incorrect, right?

This URL...
view-source:https://www.khronos.org/registry/webgl/extensions/OES_vertex_array_object/extension.xml
...does indeed preserve whitespace (since 'view-source:' does in general).

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Emmanuel Gil Peyrot from comment #8)
> I’d argue for this attribute to be supported even when it isn’t declared,
> based on widespread usage, but I’d be fine with only having it working when
> it is declared, as per the specification. :)

For documents where we render any sort of styling (instead of simply dumping a serialized version of the DOM), I'd agree that this should probably work per spec [if the attributes are declared]. But I don't think we want to make the serialized version overly smart [e.g. letting attributes affect its rendering].  As I understand it, that view is simply intended to be a "We don't know how to render this document, so here's a quick representation because that's better than nothing".  If you want something that looks more view-source:-like, just use "view-source". :) (Ctrl+u)

Comment 11

[Emmanuel Gil Peyrot]

(In reply to Daniel Holbert [:dholbert] from comment #9)
> To be clear, "view-source:" in the bug-summary here is incorrect, right?
> 
> This URL...
> view-source:https://www.khronos.org/registry/webgl/extensions/
> OES_vertex_array_object/extension.xml
> ...does indeed preserve whitespace (since 'view-source:' does in general).

Indeed, this is incorrect.

(In reply to Daniel Holbert [:dholbert] from comment #10)
> For documents where we render any sort of styling (instead of simply dumping
> a serialized version of the DOM), I'd agree that this should probably work
> per spec [if the attributes are declared]. But I don't think we want to make
> the serialized version overly smart [e.g. letting attributes affect its
> rendering].  As I understand it, that view is simply intended to be a "We
> don't know how to render this document, so here's a quick representation
> because that's better than nothing".  If you want something that looks more
> view-source:-like, just use "view-source". :) (Ctrl+u)

This might be sensible, but supporting all of the presentation attributes from the XML specification would also be sensible, I don’t know.

Comment 12

[[:mirabilos]]

I just ran into the same issue. I’m collecting metadata about files on my site, and unstyled XML is currently the best way to present them to casual viewers. Some of the metadata needs whitespace preserved, and Firefox does not seem to support that.

The other browser I tried (lynx) just loads the file in an editor, since it’s served as application/xml, so it sorta preserves them ☻

Comment 13

[[:mirabilos]]

Attachment: 1204553.xml

Comment 14

[[:mirabilos]]

Even the testcase I just attached (also online, served as Content-Type: application/xml) with an inline DTD won’t work, so unfortunately, this cannot be used to work around this bug: Firefox ignores the xml:space even if not only present but also defined (as requested in comment #7).

Firefox does parse and use the DTD, as can be seen by it showing e.g. <info name="ICOP" xml:space="default"> in the formatted XML view whereas the document has <info name="ICOP">, i.e. it adds the default value.

However, despite displaying <info name="ICMT" xml:space="preserve">, the resulting text is mangled.

To add insult to injury, ^U shows the entire inline DTD in red undersquiggles, with a hover text of “Bogus comment.” (wtf‽), so there are apparently multiple things going wrong.

To make it fully clear: yes, I expect xml:space to work in the formatted XML view in that whitespace must not be collapsed. I would additionally be happy if the monospace font would be used to display tags with that attribute set.

Comment 15

[[:mirabilos]]

reconfirmed in 115.4.0esr btw, but I cannot seem to set this in the metadata here

Comment 16

[Daniel Holbert [:dholbert]]

Thanks for the notes and the testcase.

(In reply to [:mirabilos] from comment #14)

Even the testcase I just attached (also online, served as Content-Type: application/xml) with an inline DTD won’t work, so unfortunately, this cannot be used to work around this bug: Firefox ignores the xml:space even if not only present but also defined (as requested in comment #7).

To clarify comment 7, that was me digging up & speculating about what the spec calls for (and hence what-might-be-reasonable-to-expect-from-an-XML-viewer-that-conforms-to-the-XML-spec), not what Firefox actually does.

To add insult to injury, ^U shows the entire inline DTD in red undersquiggles, with a hover text of “Bogus comment.” (wtf‽), so there are apparently multiple things going wrong.

That's maybe worth filing as a distinct bug, and CC :hsivonen who works on our parser.

To make it fully clear: yes, I expect xml:space to work in the formatted XML view in that whitespace must not be collapsed. I would additionally be happy if the monospace font would be used to display tags with that attribute set.

For comparison-between-web-engines, it seems Chrome displays XML files with a monospace font. That seems like a good idea in general, perhaps. But like Firefox, they collapse whitespace despite xml:space="preserve".

(In reply to [:mirabilos] from comment #15)

reconfirmed in 115.4.0esr btw, but I cannot seem to set this in the metadata here

Yeah, reconfirmed in Firefox 121 Nightly here. It's fine to not update metadata for which-versions-are-affected for longstanding bugs like this (representing every-affected-Firefox-version would be quite cumbersome). I've just adjusted Version to Trunk.

Fair warning, I don't think the XML viewer gets a lot of active development, so don't take my response here as any sort of promise-of-a-fix-coming-soon. :)

Comment 17

[[:mirabilos]]

I reported the corresponding issue against Google Chrome. I do not normally have access to Safari or Internet Exploder or what’s its name.

lynx just downloads the file (as it’s served as application/xml) and, for text/xml, probably would just display it as-is.

links2 does display it as-is, so no fancy collapsing, etc. but also no breaking of whitespace.

Konqueror 3 strips all tags and attributes and just displays the raw CDATA, as does Opera 9.64 ☹

Konqueror 5, like Chromium, behaves like Firefox but at least does choose a monospace font for the entire rendered XML tree, which already is an improvement.

Firefox 1.5 behaves the same as 115.

Comment 18

[Henri Sivonen (:hsivonen) (not reading bugmail until 2026-07-27)]

Firefox is always preserving white space in the sense meant by the XML processor / application split in the XML spec. That is, all of it ends up in the DOM.

It indeed would be nice if the transformation of unstyled XML special-cased xml:space, though. Perhaps peterv knows how easy or hard it would be to make the transformation make xml:space="preserve" parts of the input have white-space: pre-wrap in the output.

Comment 19

[Peter Van der Beken [:peterv]]

Attachment: Bug 1204553 - xml:space="preserve" isn’t respected in the no-style-information "document tree" presentation of an XML document. r?hsivonen!

Comment 20

[[:mirabilos]]

Is pre-wrap wise though, as opposed to just pre and (if needed) horizontal scrolling for the whole enclosing tag?

I think one would need to experiment with both a little. I guess if needed, F12 can be used to change this, too.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9a7906e05756
xml:space="preserve" isn’t respected in the no-style-information "document tree" presentation of an XML document. r=hsivonen

Comment 22

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/9a7906e05756