Bug 14114 – REGRESSION: HTMLElement.localName returns lowercase, breaks Jira

• Status: RESOLVED
• Resolution: INVALID
• Component: Evangelism

[Mike Aizatsky]

After upgrading to Safari 3 Beta "Edit" and "Resolve" links are not clickable on JIRA. The same is true for WebKit nightly. 

See the archive of the page attached. "Resolve Issue" & "Edit" in the left pane do not work. Middle click doesn't work too. I'm forced to use "Open link in new tab" on them.

[Mike Aizatsky]

Created attachment 14993 [details]
Archive which demonstrates the problem

[David Kilzer (:ddkilzer)]

Confirmed with Safari 3.0 beta and a local debug build of WebKit r22098 on Mac OS X 10.4.9 (8P135).

When the "Edit" or "Resolve Issue" links are clicked (on the left side of the page), a JavaScript error occurs.  The JavaScript Console (available through the hidden Debug menu) says in both cases:

Null value
http://www.jetbrains.net/jira/s/210/1/1.0/_/download/resources/jira.webresources:issueoperations/issueoperations.js
Line: 101

Console output:

(event handler):Null value

[Mike Aizatsky]

Just a note: it worked in Safari 2.

[Mike Aizatsky]

Here's the code from file. Line 101 is marked:

-------------
    // Handles the onclick events for decorated links. Hides issue content and displays
    // the contents of the link in a new iframe undecorated
    var switchBodyDiv = function(event)
    {
        YAHOO.util.Event.preventDefault(event);
        var issueContentElem = document.getElementById('issueContent');
        if(issueContentElem != null)
        {
            // Delete existing iframe
            deleteElement('issueContentIfrmContainer');

            // Create new iframe
            var anchor = findParentElement(YAHOO.util.Event.getTarget(event), "A");
[101]            var url = addParameterToUrl(anchor.getAttribute("href") + "", "decorator=basic");

            var ifrmContainerDiv = document.createElement('DIV');
            ifrmContainerDiv.id = 'issueContentIfrmContainer';
            ifrmContainerDiv.innerHTML = ' <iframe id="issueContentIfrm" src="' + url +
                                                    '" scrolling="no" onload="ATLASSIAN.JIRA.issueoperations.reformatFrame()" scrolling="no" style="border:0px; width: 100%; padding: 10px; height: 0px;" frameborder="0"> </IFRAME>';

            issueContentElem.parentNode.appendChild(ifrmContainerDiv);
        }
        return false;
    };

[David Kilzer (:ddkilzer)]

(In reply to comment #3)
> Just a note: it worked in Safari 2.

Giving this bug the full regression treatment.

[David Kilzer (:ddkilzer)]

(In reply to comment #4)
> Here's the code from file. Line 101 is marked:

Thanks, Mike!  If you'd like to help further, you can do so by reducing the failing JavaScript to the smallest amount of JavaScript and HTML code required to reproduce the issue.  (Using the Drosera debugger from the WebKit Nightly builds may help as well, although it's a bit slow even on a MBP.)

[Mike Aizatsky]

David,

I've localized the issue:

it looks like 'node.localName' changed its behavior. I can't be completely sure but it looks like the only explanation of it working:

in the js code findParentElement in line 100 returns null. It's implemented as:

    var findParentElement = function (element, parentNodeName)
    {
        while((element != null) && (element.localName != null) && (element.localName != parentNodeName)) {
            element = element.parentNode
        }
        return element;
    };

and is called with the following parameters:

findParentElement(YAHOO.util.Event.getTarget(event), "A");

It looks like Safari returned upper case letters (which is probably for HTML afaik), and Safari 3 is (for some reason) returning lower case.

Does it make any sense for you?

[David Kilzer (:ddkilzer)]

(In reply to comment #7)
> Does it make any sense for you?

Yep, that's the problem!  Thanks!

[David Kilzer (:ddkilzer)]

Created attachment 15010 [details]
LayoutTest test case

Please place this file in LayoutTests/fast/dom to run it.

Note that both <A> and <a> tags return "a" for the localName attribute in Safari 3.0 beta.  The fix is probably to do a case-insensitive check in Jira's JavaScript code.

[David Kilzer (:ddkilzer)]

Note that both Opera 9.21 and Firefox 2.0.0.4 return "A" for both test cases in Attachment #15010 [details].

What does MSIE 6/7 return?

Is there a standard for capitalization of HTML tag names returned via the "localName" attribute (in quirks mode versus standard mode, HTML versus XHTML)?

[Mike Aizatsky]

> The fix is probably to do a case-insensitive check in Jira's
> JavaScript code.


There're two problems:

1) I'm not a JIRA guy
2) There're _so many_ jira installations in the wild - this way simply isn't practical.

[Mike Aizatsky]

http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-104682815

I would suggest that it should be upper case for HTML:

The HTML DOM returns the tagName of an HTML element in the canonical uppercase form, regardless of the case in the source HTML document.

[Mike Aizatsky]

And more (from the same document):

Note that HTML processors often perform specific case normalizations (canonicalization) of the markup before the DOM structures are built. This is typically using uppercase for element names and lowercase for attribute names.

[David Kilzer (:ddkilzer)]

<rdar://problem/5286449>

[Maciej Stachowiak]

IE does not support localName on HTML elements at all. Does this library support IE? The DOM specs do require tagName and nodeName to be uppercase in HTML documents but don't appear to say anything about localName.

[Ian 'Hixie' Hickson]

HTML5 currently lumps localName in the same bucket as tagName, fwiw. Let me know if I should change that.

[Ian 'Hixie' Hickson]

By popular request, HTML5 changed to do what Webkit does for localName, making this bug invalid per spec. It's been open over a year, is it still a problem? Seems the site is down.

[Adam Barth]

Created attachment 68209 [details]
regression test

[Alexey Proskuryakov]

Comment on attachment 68209 [details]
regression test

+<html>

Would it make sense to test strict mode? XHTML?

+if (window.layoutTestController)
+    layoutTestController.dumpAsText();

I think js-test-pre.js does this for us.

[Adam Barth]

> Would it make sense to test strict mode? XHTML?

I made a strict mode one.  XHTML was too hard to author, so I gave up.  :(

> I think js-test-pre.js does this for us.

Yep.

[Adam Barth]

Created attachment 68356 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 68356 [details]
Patch for landing

Clearing flags on attachment: 68356

Committed r68034: <http://trac.webkit.org/changeset/68034>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Alexey Proskuryakov]

Thanks Adam!

Marking WONTFIX, as we're not fixing the bug as reported.

[David Kilzer (:ddkilzer)]

Moving to Evangelism.

[Alexey Proskuryakov]

Why? Hasn't Jira been fixed already?

[David Kilzer (:ddkilzer)]

(In reply to comment #26)
> Why? Hasn't Jira been fixed already?

Has this been confirmed by anyone?  I don't have an instance of Jira to test with.

Mike Aizatsky, is this fixed in a more recent version of Jira?

[David Kilzer (:ddkilzer)]

(In reply to comment #26)
> Why? Hasn't Jira been fixed already?

JetBrains still has their instance of Jira running, but all the issues redirect to YouTrack (their own bug tracking tool), so I can't see the original bug view in the attached webarchive.

Also, Atlassian's Jira <http://jira.atlassian.com/> is running a newer version.  I don't have "editbugs" permission on that one, either, so I can't tell if this is still an issue or not.

[David Kilzer (:ddkilzer)]

Moving back to last status: RESOLVED INVALID.

Please file a new bug for any remaining issues with Jira.