Wrong version number on Safari

[lehni]

According to http://api.jquery.com/jquery.browser/#jQuery-browser-version2, jQuery.browser.version is supposed to be the browser's rendering engine version number, not the version number of the browser itself.

But on Safari 8 I get 8.0, while http://code.jquery.com/jquery-migrate-1.2.1.js gives the correct 600.1.22

[le717]

@lehni Personally, I prefer the current behavior of returning the actual version number instead of the engine number, even if it wrong according to the documentation and migrate plugin. In most cases, 8.0 is more useful and meaningful than 600.1.22, although there may be those who prefer the other (and I guess you're in that position, correct)?

[lehni]

Regardless of what's more useful, what's the point of emulating the jQuery functionality and naming, if it doesn't behave the same way?

We've run into an issue where we were using it as a drop in replacement for the removed jQuery functionality, and it's been causing troubles with this statement somewhere deep down in the code of http://www.wymeditor.org:

    if (jQuery.browser.version < 534.1) {
        // Not needed in AT MAX chrome 6.0. Probably safe earlier
        if (evt.which === WYMeditor.KEY.ENTER && evt.shiftKey) {
            wym._exec('InsertLineBreak');
        }
    }

There's no issue with making a plugin that behaves differently, but then you shouldn't name it the same as the functionality that it is meant to replace, and claim that the removed jQuery functionality "was abstracted into a jQuery plugin". That's simply not the case here.

[lehni]

What I'm saying is basically this: It's not a question of preference in this case, as it a question of wether this plugin is capable of providing a functionality that went missing in jQuery, and that other plugins that we work with still depend on. And the fact that it doesn't do this seems counter-intuitive and confusing, especially after consulting the docs.

[le717]

I get what you mean, don't worry about that. If there is a backward-incompatible change, it should have been documented.

I've tracked down two possible commits that might have caused this, but in both of them + the latest version from master, $.browser.version is returning 600.1.22 for my fabricated Safari 8 UA. Could you post the Safari 8 user-agent you have? Mine could be wrong, as it is based on the Safari 7 UA, and I could not find an v8 one.

Mozilla/5.0 (iPad; CPU OS 8_0 like Mac OS X) AppleWebKit/600.1.22 (KHTML, like Gecko) CriOS/30.0.1599.12 Mobile/11A465 Safari/8536.25 (3B92C18B-D9DE-4CB7-A02A-22FD2AF17C8F)

[le717]

OK, I found the issue and bad commit. I was using an iOS user agent, where this is not an issue, instead of an Mac OS X user agent, where I can repro it. I've traced the bad commit to db2edb1.

@gabceb As it turns out, the proper engine number was already being extracted, it was just unused. I will submit a PR with a fix, but this will be some breaking changes, and I still working on not breaking behavior on other browsers.

[le717]

@lehni A fix is up at #37, please let me know if that fixes it for you.

[lehni]

Great, that works for me, thanks a lot for fixing so quickly!

[mightyiam]

@lehni BTW you're invited to contribute to upstream WYMeditor.

[mightyiam]

@lehni we've just made some improvements to browser detection.