Closed Bug 566629 Opened 13 years ago Closed 12 years ago

XSLT uppercasing name() function in XHTML documents

Categories

(Core :: XSLT, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: wiredearp, Assigned: sicking)

References

Details

(Keywords: regression, Whiteboard: [ready to land])

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.38 Safari/533.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4) Gecko/20100407 MozillaDeveloperPreview/3.7a4

XPath name() function returns uppercase nodenames in Gecko 1.9.3 alpha 4. XPath local-name() function preserves the declared case as expected.

Reproducible: Always

Steps to Reproduce:
1. Create document or element in XHTML namespace.
2. Write XSL stylesheet, making use of the name() function.
3. Using JS API, transform the XML and view the output.
Actual Results:  
name() returns uppercase while local-name() preserves the case.

Expected Results:  
Both functions preserve nodename casing as declared in markup.

Check out the attachment, transforming live on stage to demonstrate the bug.
Attached file Testcase XHTML (obsolete) —
You're creating an HTML (not XHTML) document and passing that in to the XSLT transform.  In HTML documents, node names are uppercase (and this is required by the HTML5 spec) while localNames are in the original case.
Er, maybe not quite.  Let me look a bit more.
Nevermind comment 2.  Digging more.
We only do this on HTML elements. HTML element names are case insensitive in the markup, so it doesn't make sense to maintain the casing used in the markup. No DOM implementation does this.

We instead let the name() function return the same value as .nodeName, which in many cases is upper cased for HTML elements.
OK, so this is sort of a regression from bug 488249 and the HTML namespace changes.

In txXPathNodeUtils::getNodeName we should presumably be checking for an HTML document, right?  And in localName we should nix the check altogether, since it never passes (IsHTML() implies namespace is not none).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Note that the key is that we're NOT calling GetNodeName on the node here, but reimplementing it ourselves in the xslt treewalker.  And doing it wrong.
Blocks: 488249
blocking2.0: --- → ?
Keywords: regression
To make things worse, the mentioned uppercasing of HTML nodeNames has been changed for the XSLT implementation according to ttps://developer.mozilla.org/en/Updating_extensions_for_Firefox_3.6 - both XSLT functions are now claimed to return lowercase for ordinary HTML documents:

"The name and the local-name functions in XPath returns the name of HTML elements in lower case. Previously, in HTML documents, they returned it in upper case."

XSLT on XHTML documents now seems to partly implement a deprecated feature of HTML documents. Thanks for digging in.
Over to Jonas, this should be a trivial fix, and it is a regression, so blocking.
Assignee: nobody → jonas
blocking2.0: ? → final+
Attached patch Patch to fixSplinter Review
Trivial fix, we just want to uppercase if it's a HTML element in a HTML document.
Attachment #445976 - Attachment is obsolete: true
Attachment #481159 - Flags: review?(hsivonen)
Is uppercasing in HTML documents required for compat? That is, why would we upper-case at all?
To be consistent with how the DOM works. It's not pretty, but I'd prefer to be consistent. And people should generally use local-name() anyway.
Comment on attachment 481159 [details] [diff] [review]
Patch to fix

I wish we could get rid of the upper casing, but it's probably not worth the compat risk to try changing things too much. So, r=me.
Attachment #481159 - Flags: review?(hsivonen) → review+
Whiteboard: [ready to land]
Checked in

http://hg.mozilla.org/mozilla-central/rev/4d2eff8cc112
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Duplicate of this bug: 607925
You need to log in before you can comment on or make changes to this bug.