What is the ideal JavaScript browser detection pattern?

i.e. What's the best approach to replace the *deprecated* **jQuery.browser** property?

The **jQuery.browser** property was *deprecated* and was removed in **jQuery 1.9**.
I'm working with code that conditionally stops event propagation based on browser make and version and I'd like to find a method that won't break *if/when* Cobalt Static Content upgrades to **jQuery 1.9**.

Find more posts tagged with

jquery

static-data

refinitiv-internal

Accepted answers

All comments

Artem Saveliev

As it mentions, you can add jquery.migrate plugin to get the functionality back - this should be most painless method, if you really have to migrate (why would they remove previous jquery from static content???).

Of course you shouldn't really be doing that type of detection to begin with. Also, did you try using jquerys own event.stopPropagation? It specifically implements propagation logic for different browsers.

Ioannis Mavroukakis

jQuery has the *support* property, but even that comes with the caveat that features might disappear from under your feet ( [jQuery.support][1] ) What is widely recommended is a library called [Modernizr][2].

Taken from their website:

> Modernizr makes it easy for you to
> write conditional JavaScript and CSS
> to handle each situation, whether a
> browser supports a feature or not.
> It’s perfect for doing progressive
> enhancement easily.

HTH

[1]: http://api.jquery.com/jQuery.support/
[2]: http://modernizr.com/

Andrew Gerber

Which browsers is it specifically testing for in the scenario you mention? We may be checking for browsers we don't support any more or might not support in the near future (ex: IE7).

Dave Stanton

Browser detection is needed because the Cobalt Document module manages a Flash clipboard-injection UI element. For Firefox, IE7+8 extra mousedown and mouseup event handlers are needed and we provide a stopEventPropagationAndDefaultBehavior callback at bind-time. For Chrome, Safari, and IE9+ no extra handlers are needed. This specialization addresses how each browser class handles the JavaScript/Flash plug-in interaction. The detection happens during DOM element instantiation in the SelectedTextMenu widget.

Dave Stanton

I see. Isn't it possible the Static Content team might upgrade jQuery to 1.9? I suppose they would deal with the breaking changes then.
Actually, event.stopPropagation is used. The detection determines whether or not extra event handlers are to be bound to a menuitem element.

Looking at the code, it appears the result of the browser sniffing determines additional event binding logic running when certain browsers are in play; different mouse events are needed to support embedded Flash interaction functionality. Otherwise, the Flash object doesn't work at all.

Artem Saveliev

No idea, I don't see why you would forcefully upgrade to 1.9 if it's not needed.

Interesting, so event binding itself is not happening depending on browser-plugin interaction. It's not just the cancellation, like you mentioned on top. It really sounds like this whole flash wrapping functionality needs to be its own jquery plugin or code module, so you could upgrade it separate from rest of the code.

Andrew Gerber

At this time there is no immediate plans to upgrade to jQuery 1.9, but you are correct in that it may be done in the future. However, as part of the upgrade process, any imcompatible/breaking changes are considered and need to be resolved before upgrading. This would definitely be one of those breaking changes on the jQuery end that would need to be resolved.

EXPLORE OUR SITES