Last Comment Bug 542185 - getElementsByTagNameNS behaviour changed, breaking Facebook applications
: getElementsByTagNameNS behaviour changed, breaking Facebook applications
Status: RESOLVED FIXED
: dev-doc-needed, regression, testcase
Product: Tech Evangelism Graveyard
Classification: Graveyard
Component: English US (show other bugs)
: unspecified
: x86 All
: -- normal
: ---
Assigned To: english-us
:
:
Mentors:
http://bugs.developers.facebook.com/s...
: 536900 536941 (view as bug list)
Depends on:
Blocks: 468708
  Show dependency treegraph
 
Reported: 2010-01-26 02:07 PST by Mike Beltzner [:beltzner, not reading bugmail]
Modified: 2015-04-19 23:39 PDT (History)
18 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
working testcase (662 bytes, text/html)
2010-01-26 03:02 PST, :Gavin Sharp [email: gavin@gavinsharp.com]
no flags Details

Description Mike Beltzner [:beltzner, not reading bugmail] 2010-01-26 02:07:43 PST
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>
Comment 1 Mike Beltzner [:beltzner, not reading bugmail] 2010-01-26 02:10:08 PST
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 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-01-26 03:01:47 PST
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 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-01-26 03:02:43 PST
Created attachment 423502 [details]
working testcase
Comment 4 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-01-26 03:18:59 PST
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 Henri Sivonen (:hsivonen) 2010-01-26 03:58:49 PST
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.
Comment 6 Mike Beltzner [:beltzner, not reading bugmail] 2010-01-26 08:20:20 PST
*** Bug 536900 has been marked as a duplicate of this bug. ***
Comment 7 Mike Beltzner [:beltzner, not reading bugmail] 2010-01-26 18:59:18 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2010-01-26 20:52:40 PST
Bug 468708 did have dev-doc-needed... but as a whiteboard annotation, not a keyword.  :(  I've fixed that now.
Comment 9 Christopher Blizzard (:blizzard) 2010-01-28 10:48:11 PST
Sounds like the fix has been rolled out for this:

http://bugs.developers.facebook.com/show_bug.cgi?id=8389#c28
Comment 10 Henrik Skupin (:whimboo) 2010-01-28 11:44:07 PST
Right. At least sending gifts in Mafia Wars works again. Do we have other apps which have been failed?
Comment 11 -fullmetaljacket- 2010-02-01 02:50:35 PST
*** Bug 536941 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.