399077 - AJAX tooltips produces error: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXSLTProcessor.transformToFragment]

Status: RESOLVED DUPLICATE of bug 409768

(Tech Evangelism Graveyard :: English US, defect)

Description

[Leman Bennett [Omega]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre ID:2007100804

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre ID:2007100804

Error at the World of Warcraft Armory Site:

When you look up someone's Armory page, the information about that character's gear shows up in a tooltip when rolled over.

Example (A random profile): http://www.wowarmory.com/character-sheet.xml?r=Kel%27Thuzad&n=Food

Rollover some of the gear (the bigger icons), The tooltip will say "Loading..." but the information will never show up.

Everytime its rolled over, Error Console produces:
Error: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXSLTProcessor.transformToFragment]
Source file: http://www.wowarmory.com/js/ajaxtooltip.js
Line: 81

This works correctly in the 1.8 builds. 

Reproducible: Always

Steps to Reproduce:
1. Visit www.wowarmory.com and search for a character.
2. Open that character's profile page.
3. Rollover a gear icon for a tooltip.
Actual Results:  
Produces a tooltip that says "Loading..." and never loads in the information. 

Expected Results:  
Loaded information about that particular gear.

Comment 1

[Marcia Knous [:marcia]]

confirmed using  Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

The line in question is:
var newItemHtml = ttipXsltProcessor.transformToFragment(safariXmlRequest.responseXML,window.document);

A regression range would help pinpoint the change that is causing this problem.

Comment 3

[Martijn Wargers (dead)]

Between 2006-03-01 and 2006-03-05, it starts with 1 of those js errors in the console:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-01+04&maxdate=2006-03-05+09&cvsroot=%2Fcvsroot

Between 2006-04-05 and 2006-04-08, it starts to spew out those errors constantly when hovering over the stuff:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-04-04+04&maxdate=2006-04-08+09&cvsroot=%2Fcvsroot

Not sure if those regression ranges are good.
Someone else should probably recheck (and refine the regression range if possible).

Comment 4

[Peter van der Woude [:Peter6]]

regressionwindow for the error+failing menu (loading....) is:
works in firefox-1.6a1.en-US.win32_20060406_1148_cairo
fails in firefox-1.6a1.en-US.win32_20060406_1400_cairo

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-04-06+11&maxdate=2006-04-06+14&cvsroot=%2Fcvsroot

-> bug 332239 ?

Comment 5

[Boris Zbarsky [:bzbarsky]]

The site is passing a null aSource to TransformToFragment().  The JS stack is:

0 [native frame]
1 safariReadystateHandler([object Event @ 0x3e461a90 (native @ 0x3e4c9910)]) ["http://www.wowarmory.com/js/ajaxtooltip.js":81]
    preBufferedItemContainer = [object HTMLDivElement @ 0x3e406bd0 (native @ 0x3c0062a0)]
    newItemHtml = undefined
    nonAjaxTable = undefined
    nonAjaxTbody = undefined
    nonAjaxTr = undefined
    nonAjaxTooltips = undefined
    this = [object XMLHttpRequest @ 0x3bb53ad0 (native @ 0x3e4420f0)]

That line of JS code is (as mentioned in comment 2):

  var newItemHtml =
     ttipXsltProcessor.
       transformToFragment(safariXmlRequest.responseXML,window.document);

Apparently the responseXML is null in this case. I have no idea why; bug 332239 shouldn't have affected that.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So... The URI passed to nsXMLHttpRequest::Open is http://www.wowarmory.com/item-tooltip.xml?i=25856&r=Kel%27Thuzad&n=Food

As it happens, that's not an XML document.  It's a text/html document.  So the responseXML ends up null.  That should have been the case all along, though, so I don't see how we could have avoided this problem, unless we didn't take this codepath at all...

In a build that doesn't show this bug, what does javascript:alert(window.opera) on this page say?  What about javascript:alert(_SARISSA_IS_SAFARI) ?

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

It would be great if someone could verify that bug 332239 is indeed the cause of this. And ideally test if .responseXML being null is what caused things to break. 

If this was caused simply by us fixing bugs this might be a WONTFIX, otherwise we possibly want to block.

Comment 8

[Damon Sicore (:damons)]

-'ing.  Sayre to comment.

Comment 9

[Robert Sayre]

I checked this out. We're getting the Safari branch of their detection code. This shouldn't block unless it's failing because of a missing a capability, which I don't think is the case.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Uh... Renominating.  We got the Safari branch in 1.8 too, right?  But it worked.  The issue is the regression, not just it not working.

If we didn't use to get the Safari branch, why did we suddenly start to?

Comment 11

[Leman Bennett [Omega]]

The UA detection on the site is not detecting trunk builds as Firefox. Spoofing the UA to Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Makes the tooltips work again as intended with no errors in the console.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Oh.  Well, then.  The regression range includes the checkin with comment "Bump version on trunk to 3.0a1. b=330528 r=mconnor".

Sounds like an evangelism bug to me.  Someone needs to contact the site and point them to http://geckoisgecko.org/ because over here even a branch BonEcho-branded build fails.  So they're doing _something_ weird with their sniffing.

Comment 13

[Michael Lefevre]

I guess this is the same as bug 409768, and a report of this problem has been passed onto the site authors with a link to that bug.  This bug has more info from the Mozilla code point of view though, so I'm not entirely sure if I should dupe this bug forwards...

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This bug is also somewhat confused up until the very last comments. So duping seems like a good idea.