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.
Created attachment 14993 [details] Archive which demonstrates the problem
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
Just a note: it worked in Safari 2.
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; };
(In reply to comment #3) > Just a note: it worked in Safari 2. Giving this bug the full regression treatment.
(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.)
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?
(In reply to comment #7) > Does it make any sense for you? Yep, that's the problem! Thanks!
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.
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)?
> 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.
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.
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.
<rdar://problem/5286449>
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.
HTML5 currently lumps localName in the same bucket as tagName, fwiw. Let me know if I should change that.
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.
Created attachment 68209 [details] regression test
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.
> 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.
Created attachment 68356 [details] Patch for landing
Comment on attachment 68356 [details] Patch for landing Clearing flags on attachment: 68356 Committed r68034: <http://trac.webkit.org/changeset/68034>
All reviewed patches have been landed. Closing bug.
Thanks Adam! Marking WONTFIX, as we're not fixing the bug as reported.
Moving to Evangelism.
Why? Hasn't Jira been fixed already?
(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?
(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.
Moving back to last status: RESOLVED INVALID. Please file a new bug for any remaining issues with Jira.