Closed
Bug 542185
Opened 15 years ago
Closed 15 years ago
getElementsByTagNameNS behaviour changed, breaking Facebook applications
Categories
(Tech Evangelism Graveyard :: English US, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: beltzner, Unassigned)
References
()
Details
(Keywords: dev-doc-needed, regression, testcase)
Attachments
(1 file)
|
662 bytes,
text/html
|
Details |
From http://bugs.developers.facebook.com/show_bug.cgi?id=8389#c12
------- Comment #12 From Wei Zhu 2010-01-25 21:04:22 -------
Ok. I think this may actually be a bug in FF3.6 in its getElementsByTagNameNS
implementation. The tag we search for in <fb:serverFbml>. In FF3.5, Chrome and
Safari, searching with getElementsByTagNameNS() returns match for both
<fb:serverFbml> and <fb:serverfbml>. However, nothing is found on FF3.6. Only
when I search for <fb:serverfbml>, then it works.
Here is a sample code to illustrate the issue on FF3.6.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Strict//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html
xmlns="http://www.w3.org/1999/xhtml"xmlns:fb="http://www.facebook.com/2008/fbml"><head>
<title>XFBML test</title></head>
<body>
<fb:serverfbml id="lowerCaseTag"></fb:serverfbml>
<fb:serverfbml id="upperCaseTag"></fb:serverfbml>
<script type="text/javascript">
function check_result(element, localName) {
result = element.getElementsByTagNameNS(document.body.namespaceURI,
localName);
console.log("Search for tag " + localName);
for (var i=0; i < result.length; i++) {
var e = result[i];
console.log("Found tag " + localName + " with id = " + e.id + ", ");
}
}
</script>
<script type="text/javascript">
function $(id) {
return document.getElementById(id);
}
function test() {
check_result(document.body, "fb:serverFbml");
check_result(document.body, "fb:serverfbml");
}
window.onload = test;
</script>
</script>
</body>
</html>
|
Reporter | |
Comment 1•15 years ago
|
||
I suspect that the testcase above has a typo, and that the second fb tag should be:
<fb:serverFbml id="upperCaseTag"></fb:serverFbml>
Any reason why we changed our behaviour, here?
|
||
Comment 2•15 years ago
|
||
Looks like the same issue as bug 536900. It was caused by bug 468708, though it's not immediately obvious to me why, since the testcase doesn't use .localName directly. I guess bug 468708 changed the internal .localName getter used by getElementsByTagNameNS as well?
|
|
||
Comment 3•15 years ago
|
||
|
|
||
Comment 4•15 years ago
|
||
So what this boils down to is that given:
<serverFbml id="upperCaseTag"></serverFbml>
document.getElementsByTagNameNS(document.body.namespaceURI, "serverFbml")
Firefox 3.6: no results
Firefox 3.5: finds upperCaseTag
document.getElementsByTagNameNS(document.body.namespaceURI, "serverfbml")
Firefox 3.6: finds upperCaseTag
Firefox 3.5: finds upperCaseTag
getElementsByTagName (no "NS") finds it in all versions.
|
||
Comment 5•15 years ago
|
||
In Firefox 3.6, the DOM Level 2 view of HTML DOMs views the true, red pill, DOM. The reason for the change was HTML5-compliance. HTML5 prescribes this behavior, because it makes it easier to write code (both content JS code and browser-internal C++ code; see bug 487023) that works on both text/html-originating DOMs and application/xhtml+xml-originating DOMs once you no longer care about HTML5-incompliant UAs. WebKit was thought to have complied on this point for a long time.
The HTML parser folds A to Z to a to z, so the real DOM contains "fb:serverfbml" (in both 3.5 and 3.6). When getElementsByTagNameNS no longer case-folds, "fb:serverFbml" doesn't match "fb:serverfbml".
What surprises me is that WebKit still appears to do case-folding with getElementsByTagNameNS. Apparently there's an aspect of DOM Level 2 API behavior where WebKit doesn't comply with HTML5.
Is the JS code that calls getElementsByTagNameNS under Facebook's control in a single place? Are there other top sites that call getElementsByTagNameNS and expect the old blue-pill case folding? (getElementsByTagNameNS isn't even supported in IE.)
To paper over this on the Gecko side, the minimal change would be making getElementsByTagNameNS fold its localname argument to ASCII-lowercase when the namespace argument is http://www.w3.org/1999/xhtml. (Failing to constrain the case folding by namespace would break SVG-in-text/html scripting.)
In general, it's a bad idea to use upper case letters A to Z in extensions to text/html, because the HTML parser (since time immemorial) loses those letters and folds them to a to z. I realize that it's probably too late for Facebook to change that on the markup side, though.
|
||
Updated•15 years ago
|
Keywords: dev-doc-needed
|
|
Reporter | |
Comment 7•15 years ago
|
||
I think that this is going to be INVALID or WORKSFORME, but we still need the dev-doc, I think. Relevant comment from the Facebook bug:
------- Comment #25 From William Ren 2010-01-26 16:08:20 [reply] -------
XHTML always required lowercase tag names and attributes, and the documentation
ask all pages using xfbml tags to declare as XHTML doctype. The HTML 5.0 spec
just made it to comply with same standards and so it seems FF3.6 is now
enforcing it.
-----
Facebook plans on rolling out a fix tomorrow.
|
||
Comment 8•15 years ago
|
||
Bug 468708 did have dev-doc-needed... but as a whiteboard annotation, not a keyword. :( I've fixed that now.
|
|
||
Comment 9•15 years ago
|
||
Sounds like the fix has been rolled out for this:
http://bugs.developers.facebook.com/show_bug.cgi?id=8389#c28
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
|
||
Comment 10•15 years ago
|
||
Right. At least sending gifts in Mafia Wars works again. Do we have other apps which have been failed?
|
|
||
Updated•15 years ago
|
Assignee: nobody → english-us
Component: DOM → English US
Product: Core → Tech Evangelism
QA Contact: general → english-us
Version: 1.9.2 Branch → unspecified
|
||
Updated•10 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•