Reported by jay@kesoftware.com If you have the server return a content-type of application/x-javascript with a version parameter on it, the first time through, it works okay, but the second time through, trying to re-upgrade to the next version does not work (it still uses the old version instead.) A perl script is attached to demonstrate the behavior: #!/usr/local/bin/perl $test="Versioned Mime"; #$test="tag"; $version="1.3"; # this tests to see if a versioned mime type changes # the behaviour of a browser's javascript implementation if ($test eq "tag") { print "content-type: text/html\n\n <script language=Javascript$version>\n\n"; } else { print "content-type: application/x-javascript; version=$version\n\n"; } print <<EOF; alert ("Testing javascript actions: Attempting javascript $version code using $test"); if ("1" == 1 ) { alert("== is true; Javascript 1.3+ behaviour"); } else { alert("== is false, Javascript 1.2 behaviour"); } // this is true for javascript 1.0, 1.1 and 1.3+, false for 1.2 EOF if ($test eq "tag" ) { print "</script>\n\n"; } exit

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

DOM bugs are not my problem.

Deffered till Necko lands...

Deferring till Necko lands...

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or early M9. We will need to get on this and it cannot be postponed past the M9 milestone.

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Who owns DOM?

> Who owns DOM? It's widely known that vidur and joki do, but you could actually find out by going to http://cvs-mirror.mozilla.org/webtools/despot/despot.cgi and typing in the source pathname, hitting Enter, and learning who owns that partition. Or (I know there is cruft in this doc, it comes from despot too) just read http://www.mozilla.org/owners.html. Is this a DOM bug? I'm interested in how you find MIME parameters such as ;version= that come in via HTTP Content-type: too -- I'm fixing a javascript: URL bugs (see my list). /be

Was the version string taken into account in Nav4.x? If so, this is my bug and I'll have to figure out how to get the version info from the content type in HTTP headers in Necko. "Who owns the DOM?" Looks like Gagan has been in his netlib cave for too long.

Sorry about the "Who owns DOM?" You are right I had my necko blinders on :) As for the version string... I don't think we checked for it in 4.x But we should now. As is with any other MIME header- The correct way to handle all mime headers is to look for the delimiters "\n;\0" in that order. A simple strtok should do the trick.

4.x did not respect any version MIME parameter for application/x-javascript or text/javascript (the latter is not yet official, so we should use the x- type). That's a bug we should fix in 5.0, right? 4.x did respect charset= (look in network/protocol/js/mkmocha.c for charset), and Mozilla must respect that parameter too, so localized .jsu files (utf-8 encoded JS src files) work. Vidur, tao, should this be a separate bug? /be

We can get to beta without this: moving to M15. (I'm not actually sure this is a DOM bug proper, but I think vidur owns script-context creation too.)

I think the stickiness bug was peculiar to MozillaClassic, but I'll verify that this is closed when I check in JS version checking changes. /be

This is so not a bug in the new world of content sinks, which I've just hacked to respect JS versions. /be

Could somebody with Perl and a server test this to verify that it is fixed. It is very old.