Closed Bug 542185 Opened 14 years ago Closed 14 years ago

getElementsByTagNameNS behaviour changed, breaking Facebook applications

Categories

(Tech Evangelism Graveyard :: English US, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: beltzner, Unassigned)

References

()

Details

(Keywords: dev-doc-needed, regression, testcase)

Attachments

(1 file)

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>
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.

Attachment

General

Created:
Updated:
Size: