Last modified: 2012-04-12 13:54:48 UTC
Firefox version numbers are going up waaaaay faster since the new release schedule this year; 10 will be coming up in a few months. This code ain't gonna cut it: // For accesskeys; note that FF3+ is included here! window.is_ff2 = /firefox\/[2-9]|minefield\/3/.test( clientPC ); It's also pretty generally wrong and should probably not be being used by anything. :P
(In reply to comment #0) > Firefox version numbers are going up waaaaay faster since the new release > schedule this year; 10 will be coming up in a few months. > > This code ain't gonna cut it: > > // For accesskeys; note that FF3+ is included here! > window.is_ff2 = /firefox\/[2-9]|minefield\/3/.test( clientPC ); > > It's also pretty generally wrong and should probably not be being used by > anything. :P ;) On the plus side, once Firefox hits version 20 that code will start working again. It's a shame browsers don't expose their accesskey prefixes in some api.
(In reply to comment #0) > It's also pretty generally wrong and should probably not be being used by > anything. :P +1. However, we should also check that jquery.client.js (which is the recommended way of doing browser version detection now) can handle FF versions >=10.
What the heck... if ( val === false ) { return false; } else if ( typeof val == 'string' ) { if ( !( eval( 'profile.version' + op + '"' + val + '"' ) ) ) { return false; } } else if ( typeof val == 'number' ) { if ( !( eval( 'profile.versionNumber' + op + val ) ) ) { return false; } } in jquery.client's test() method, which is used to test the found data against whitelist/blacklist maps. This just looks ALL KINDS of wrong. First, eval() -- always bad. Second, if doing greater-than/less-than comparisons with strings -- as with the '7.0.1' or '10.0.0' that you might get from Firefox -- that's gonna fail utterly. Of course browser version sniffing is almost ALWAYS the wrong thing to do, so nothing *should* be doing these sorts of comparisons anyway...
Where'd you get that code? Since just about the only valid browser testing there is, is the accesskey stuff I'm starting to think we should ditch the whole is_* stuff and $.browser and the accesskey stuff should test for known user agents itself. That said, we still don't know what Firefox is going to do. This kind of crap code has been around for awhile. It's possible Firefox might try to hack it's way around it. Dare I say, Firefox could suddenly jump from 9.*.* to version 20.*.*, or maybe they'll pull an Opera with something like `Firefox/9.8.0 Version/10.0.0`.
Where'd I get it? jquery.client.js's test() method, like I said...
And btw you can download Firefox 10 nightlies *right now* from http://nightly.mozilla.org/ User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111103 Firefox/10.0a1
I added some more qunit tests for jquery.client in r101845, as well as sample UA entries & profiles for IE 10 and Firefox 10 (using the documented & confirmed-on-developer-preview IE 10 user-agent and an actual user-agent from a Firefox 10 nightly build). The sample compatibility map from WikiEditor that the tests use works on FF 10 and IE 10, but only because it's comparing numbers against the extracted major version number.
*sigh* like Bug #32047, I'm afraid this will end up in us patching jquery. Reported upstream: https://forum.jquery.com/topic/version-sniffing-is-wrong-and-will-break
isn't that one of our modules that we wrote for MediaWiki and not from upstream anywhere ?
(In reply to comment #9) > isn't that one of our modules that we wrote for MediaWiki and not from upstream > anywhere ? I think it came from *somewhere*. Trevor would know. test() is our code but I don't think profile() is originally ours.
- removing upstream as this is our own wikibits - marking WONTFIX as all of wikibits is deprecated and jquery.client.profile() doesn't have this bug
