Closed Bug 542185 Opened 14 years ago Closed 14 years ago
Elements By Tag Name NS behaviour changed, breaking Facebook applications
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?
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?
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.
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.
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.
Bug 468708 did have dev-doc-needed... but as a whiteboard annotation, not a keyword. :( I've fixed that now.
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: 14 years ago
Resolution: --- → FIXED
Right. At least sending gifts in Mafia Wars works again. Do we have other apps which have been failed?
Assignee: nobody → english-us
Component: DOM → English US
Product: Core → Tech Evangelism
QA Contact: general → english-us
Version: 1.9.2 Branch → unspecified
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.