Skip to content
Permalink
Browse files

Added in jQuery.browser.firefox, deprecated jQuery.browser.mozilla.

  • Loading branch information
jeresig committed Dec 9, 2009
1 parent 841f9ff commit 17791c9a3e8a88e129a6956e7053b964d7b34778
Showing with 5 additions and 2 deletions.
  1. +5 −2 src/core.js
@@ -620,18 +620,21 @@ jQuery.extend({
return ret.concat.apply( [], ret );
},

// Use of jQuery.browser is deprecated.
// Use of jQuery.browser is frowned upon.

This comment has been minimized.

Copy link
@jdalton

jdalton Dec 9, 2009

Member

instead of "frowned upon", why not explain it a bit more something like, "Most of the time you can avoid UA sniffing by using feature test/inference. Sniffing is used for things that have no known FT, like visual bugs or bfcache bugs. A bad feature inference can cause as many problems as a sniff for example MooTools recently dealt with the document.getBoxObjectFor issue.

// It's included for backwards compatibility and plugins,
// although they should work to migrate away.
browser: {
version: (/.*?(?:firefox|safari|opera|msie)[\/ ]([\d.]+)/.exec(userAgent) || [0,'0'])[1],
safari: /safari/.test( userAgent ),
opera: /opera/.test( userAgent ),
msie: /msie/.test( userAgent ) && !/opera/.test( userAgent ),
mozilla: /mozilla/.test( userAgent ) && !/(compatible|webkit)/.test( userAgent )
firefox: /mozilla/.test( userAgent ) && !/(compatible|webkit)/.test( userAgent )

This comment has been minimized.

Copy link
@kangax

kangax Dec 9, 2009

What's the reason for such misleading change? Camino, Seamonkey, Flock, Fennec, and even Netscape Navigator (on my mac) now all report themselves as "firefox".

}
});

// Deprecated
jQuery.browser.mozilla = jQuery.browser.firefox;

if ( indexOf ) {
jQuery.inArray = function( elem, array ) {
return indexOf.call( array, elem );

8 comments on commit 17791c9

@jdalton

This comment has been minimized.

Copy link
Member

@jdalton jdalton replied Dec 9, 2009

why not name it gecko, for browsers like camino ? and instead of safari, webkit (so chrome would be included)

@brendo

This comment has been minimized.

Copy link

@brendo brendo replied Dec 9, 2009

Feature testing is nice for some things, but I've yet to see something to help detect things like CSS selectors.

For example, I know IE doesn't support :nth-child, so I use $.browser.msie and use Sizzle to apply the class/css rules instead of having to make specific IE hacks, or add extra classes etc. Same thing goes for IE6 :hover support, I just add it via Sizzle.

How could I do those things if browser sniffing was removed?

@paulirish

This comment has been minimized.

Copy link
Member

@paulirish paulirish replied Dec 9, 2009

I'd say if you're addressing the browser object, it's the right time to throw in webkit, so we can pick up Chrome without being totally confusing.
Along with that, gecko seems far more appropriate.

@appden

This comment has been minimized.

Copy link

@appden appden replied Dec 9, 2009

I am shocked you (a Mozilla employee) are marginalizing Camino :-)

@appden

This comment has been minimized.

Copy link

@appden appden replied Dec 9, 2009

Full disclosure: I'm guilty of doing this as well in the MooTools 2.0 branch, and I'll probably fix it.

@jaubourg

This comment has been minimized.

Copy link
Member

@jaubourg jaubourg replied Dec 9, 2009

My, my, my! This commit is getting attention.

I'm wondering if we wouldn't need something like renderingEngine and javascriptEngine together with the browser information (afaik, chrome and safari share the same rendering engine but not the same javascript engine). Would simplify this kind of debates : browser would be about the app, the other two about the internals.

@jeresig

This comment has been minimized.

Copy link
Member Author

@jeresig jeresig replied Dec 9, 2009

We were discussing this and right now (in 1.3.2) jQuery.browser is a mixture of browser rendering engine versions and browser versions, along with a mixture of browser names and engine names. The previous commit gets us closer to at least some form of parity (everything is browser version and the names are all browsers). Granted there will still be a bit of weirdness (non-Firefox browsers matching Firefox) but that's another issue entirely. We /could/ go through and add in a new jQuery.engine.version/jQuery.engine.* (engine names) but that's another endeavor and, at this point, we really shouldn't be trying to add more engine/browser detection code - as it stands the previous commit was strictly fixing 3 bugs.

As far as the deprecated verbiage goes we've already discussed this extensively in the documentation page itself:
http://docs.jquery.com/Utilities/jQuery.browser

We had it marked as deprecated, but that's not true as we can't in good conscience remove jQuery.browser without breaking a number of jQuery plugins. We're continuing to actively encourage people to use feature detection and move away from jQuery.browser.

I'll follow-up to resolve the Firefox/Mozilla issue.

@jeresig

This comment has been minimized.

Copy link
Member Author

@jeresig jeresig replied Dec 9, 2009

Tried to provide a little more clarity here: 9d8bd16
The previous commit that I mentioned is here: d3dc2d1

And just to be clear: I'd much rather have a list of rendering engines and the version be the rendering engine. Unfortunately we sort of have the options that we now (likely because of the poor name choice used in jQuery.browser) and should just continue to encourage people to move away from jQuery.browser to something smarter.

Please sign in to comment.
You can’t perform that action at this time.