409768 - eu.wowarmory.com and www.wowarmory.com - Sends XHTML instead of XML (bad MIME type) in response to a xmlhttprequest from a non-Firefox Gecko browser

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English Other, defect)

Description

[Marcus Münch]

On the reported website (World of Warcraft Arsenal) normally some detailed information about the items will be loaded when moving the mouse over some item. With the Gecko version used in Firefox 3 this does not work. You will get the tooltip "Loading..." on mouseover, but the content will never show up. I tested this with the current FF3 Beta 2 on Mac (Intel) and Windows XP, both have the same behaviour.
It's not since FF3 Beta 2 this is broken, even on pre alpha versions this did not work.
As far as I know FF3 is the only browser where this does not work, so I do not expect a bug on the website (but I am not a JavaScript coder).

Comment 1

[Ria Klaassen (not reading all bugmail)]

When I change my user agent string to Firefox it works. So probably the site is sniffing for the word "Firefox" in the UA string and not "Gecko" as it should.

Comment 2

[Marcus Münch]

Hm, my useragent on Mac is Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de-DE; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2, so it contains Firefox but does not work. I have general.useragent.extra.firefox set to "Firefox/3.0b2", general.useragent.security set to "U" and general.useragent.locale set to "de-DE". Is there anything else I can tweak with about:config?

Comment 3

[Frank Wein [:mcsmurf]]

I'm not sure if "Minefield" is really the problem (also because Marcus does not have it in his UA). The browser-detection code does this for Mozilla products in http://eu.wowarmory.com//shared/global/third-party/detection.js:
    var is_gecko = ((navigator.product)&&(navigator.product.toLowerCase()=="gecko"))?true:false;
    var is_gver  = 0;
    if (is_gecko) is_gver=navigator.productSub;

var is_moz   = ((agt.indexOf('mozilla/5')!=-1) && (agt.indexOf('spoofer')==-1) &&
               (agt.indexOf('compatible')==-1) && (agt.indexOf('opera')==-1)  &&
               (agt.indexOf('webtv')==-1) && (agt.indexOf('hotjava')==-1)     &&
               (is_gecko) && 
               ((navigator.vendor=="")||(navigator.vendor=="Mozilla")|| (agt.indexOf('firefox')!=-1));
    if (is_moz) {
       var is_moz_ver = (navigator.vendorSub)?navigator.vendorSub:0;
       if(!(is_moz_ver)) {
           is_moz_ver = agt.indexOf('rv:');
           is_moz_ver = agt.substring(is_moz_ver+3);
           is_paren   = is_moz_ver.indexOf(')');
           is_moz_ver = is_moz_ver.substring(0,is_paren);
       }
       is_minor = is_moz_ver;
       is_major = parseInt(is_moz_ver);
    }

is_moz should be true here as (navigator.vendor == "") is true, is_gecko is true and the rest should also be true. Not sure though if it matters what is_minor and is_major return here. At first glance it looks like minor and major are only used for the Netscape Navigator and IE cases, but the whole browser-check code there is quite complicated and I'm not sure why/if they actually need to know what exact browser version someone is using.
Anyway, moving to General, this is probably not a JS bug, maybe not even a Mozilla bug, but a bug in the code of the website (aka Tech Evanglism).

Comment 4

[Frank Wein [:mcsmurf]]

Ok, I think I found the problem:
For getting the response, it uses this code in http://eu.wowarmory.com/js/ajaxtooltip.js:
     function safariReadystateHandler() {
         if(safariXmlRequest.readyState == 4) {
            var preBufferedItemContainer = document.createElement("div");
             if(_SARISSA_IS_SAFARI || window.opera) {
                 preBufferedItemContainer.innerHTML = safariXmlRequest.responseText;
             } else {
                 var newItemHtml = ttipXsltProcessor.transformToFragment(safariXmlRequest.responseXML,window.document);
                 preBufferedItemContainer.innerHTML = "";
                 preBufferedItemContainer.appendChild(newItemHtml);
             }

For Firefox, it uses the else case. But as the server sends some XHTML chunk with Content-Type text/html, responseXML is null here (as the response is no real XML). And an empty response cannot be parsed (it needs to use responsText, not sure what IE does here).
Ria: I wonder why it works for you, from the code it looks like it cannot work for Gecko-like browsers.

Comment 5

[Ria Klaassen (not reading all bugmail)]

When I change the value of general.useragent.override to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2 it works. It regressed also in the month that "Firefox" in the UA string was changed to "Minefield". I have only Windows to test :).

Comment 6

[Frank Wein [:mcsmurf]]

Looks like the server sends valid application/xml (real XML) when you use a Firefox-UA like Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 for the request (like GET /item-tooltip.xml?i=21871&r=Sen%27jin&n=Shish). Then responseXML then has a non-empty value. But with another UA like Firefox/3.0 or whatever it sends a XHTML response with text/html. So it's a server-side problem, it seems to look for the version after the "Firefox/" string in the UA, if it's a known(?) Firefox version, it sends XML as response, if not, it sends XHTML (sent as html/text).
Over to TE.

Comment 7

[Frank Wein [:mcsmurf]]

Marcus: Do you have a forum account for http://forums.wow-europe.com/board.html?forumId=11088&sid=1? If yes, could you then post something to their forums about the pop-up not working with the new Firefox Beta version and with other browsers like SeaMonkey, etc. which also use Gecko? You can link to https://bugzilla.mozilla.org/show_bug.cgi?id=409768#c6 as explanation why it does not work. They should better sniff for the Gecko version in the User-Agent if they need to know with which browser they are dealing with. They can look at http://developer.mozilla.org/en/docs/Gecko to see what Gecko version corresponds to which browser (just check for geckoVersion >= 1.8 for example).

Comment 8

[Frank Wein [:mcsmurf]]

Oh and if they need some algorithm on how to sniff for the Gecko version, then they can take a look at http://archive.bclary.com/lib/js/geckoGetRv.js. Won't help with trunk (beta) versions, but works with final versions as these have a well-formed Gecko version.

Comment 9

[Chris Lawson (gone)]

Blocking 334967, since this is broken sniffing.

Comment 11

[Frank Wein [:mcsmurf]]

Marcus (or anyone else who has a WoW forum account): I see there is already a thread under http://forums.wow-europe.com/thread.html?topicId=2111802583&sid=1 (or did you make that one?). Can you add a reply there with a link to https://bugzilla.mozilla.org/show_bug.cgi?id=409768#c6 as this comment states what the problem is?

Comment 12

[Marcus Münch]

Frank, sorry for answering so late, it's christmas time and family visiting time ;-). Yes, I have a forum account and will post your link immediately.

Comment 13

[Frank Wein [:mcsmurf]]

No problem, was just doing a bit of bug cleanup.

Comment 14

[Marcus Münch]

Ok, it seems that the people of Blizzard are aware of this problem now:

"* 2. Re: Firefox 3.0bX  |  27/12/2007 08:36:59 CET

      quote reply 

Thanks for your report. I will pass it along to the Armory team for further investigation.

Thanks!

Daliniya English Web Editor"

Comment 19

[Erik Chendo Tegon]

www.wowarmory.com have the problem too.
With the firefox 3 beta 4 too

Comment 20

[Michael Lefevre]

Yes, www.wowarmory.com and eu.wowarmory.com are separate sites, but they run the same code - the US (www) version tends to get updates first actually.

As comment 8 said, this seems to happen with a Firefox version that is not specifically known to their code, so it will presumably happen with any version higher than 2 until they fix it. Certainly happens with a user agent of "Firefox/3.0"

Comment 23

[Michael Lefevre]

WoW armory item tooltips are now working for me, with a user agent containing Firefox/3.

It works spoofing something like the UA that will be in Firefox 3 final, and it works with Firefox 3 beta 5, but still doesn't work with a minefield user agent, but I guess we can live with that.

Marking fixed.

Comment 24

[Jeff Walden [:Waldo]]

So does it not work with something like Camino, then?  I see at least one Camino user in the CC list who I'm sure can reopen this if that's the case.  :-)

Comment 25

[Michael Lefevre]

I guess the recent change to Camino's user agent string to include a "like Firefox" part (bug 384721) may make this work for Camino users too.  Not sure about Seamonkey...

Comment 26

[Frank Wein [:mcsmurf]]

Well, doesn't work in SeaMonkey. And the fact that it still does U-A spoofing is not good. Remember, TE is about all Gecko products, not only Firefox :).

Comment 27

[Chris Lawson (gone)]

(In reply to comment #23)
>but still doesn't work with a minefield user
> agent, but I guess we can live with that.

No, absolutely not. I recognise that two other people have said this already, but as one of maybe four people who are fairly active in TE, fixing things so they work in Firefox and ONLY in Firefox is absolutely unacceptable. Have a look at bug 334967, which this bug still blocks, for some idea of why; I'd rather not rehash all the arguments here.

Comment 30

[Chris Lawson (gone)]

INCOMPLETE due to lack of activity since the end of 2009.

If someone is willing to investigate the issues raised in this bug to determine whether they still exist, *and* work with the site in question to fix any existing issues, please feel free to re-open and assign to yourself.

Sorry for the bugspam; filter on "NO MORE PRE-2010 TE BUGS" to remove.

Comment 31

[Wayne Woods]

The old armory has been replaced. The new version does work properly with the latest Minefield 4.0 betas. So it could even be invalidated.

Comment 32

[Chris Lawson (gone)]

FIXED, then.