Side navigation
#12333 closed bug (fixed)
Opened August 17, 2012 04:18PM UTC
Closed August 21, 2012 03:10AM UTC
Last modified August 24, 2012 05:45PM UTC
$.browser.webkit (undefined) -> $.browser.chrome
Reported by: | Ult Combo | Owned by: | dmethvin |
---|---|---|---|
Priority: | blocker | Milestone: | 1.8.1 |
Component: | support | Version: | 1.8.0 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
$.browser.webkit
returns undefined
when using Windows' Google Chrome 22 Dev - 23 Canary in jQuery 1.8.0, but returns true
when using jQuery 1.7.2.
I noticed that version 1.8.0 introduced $.browser.chrome
(which seemingly replaces the $.browser.webkit
for Chrome browsers), but there's no documentation $.browser.chrome
in the jQuery.browser page.
Test cases:
Chrome, jQuery 1.8.0 - $.browser.chrome = true; $.browser.webkit = undefined
Chrome, jQuery 1.7.2 - $.browser.chrome = undefined; $.browser.webkit = true
Proposed patch: set the $.browser.webkit
flag to true
in jQuery 1.8 for back-compat, add documentation about $.browser.chrome
.
Attachments (0)
Change History (7)
Changed August 17, 2012 04:20PM UTC by comment:1
component: | unfiled → support |
---|---|
milestone: | None → 1.8.1 |
owner: | → dmethvin |
priority: | undecided → blocker |
status: | new → assigned |
Changed August 21, 2012 01:22AM UTC by comment:2
According to the jquery blog post at http://blog.jquery.com/2012/06/22/jquery-1-8-beta-1-see-whats-coming-and-going/ $.browser is going to be dropped completely. They mentioned they'll be making plugins for deprecated features such as this, but looks like it won't be released until 1.9. So I put together a plugin for now, and added support for fixing this bug (that i also ran into)
Changed August 21, 2012 03:10AM UTC by comment:3
resolution: | → fixed |
---|---|
status: | assigned → closed |
Fix #12333. Chrome needs $.browser.webkit too.
Changeset: 465959e75c08f7f1961071832a8c27a205bf05d0
Changed August 21, 2012 05:07AM UTC by comment:4
Thanks for the fix, and also thanks b.n.williams for the plugin, in case the worst happens in the future. I know $.browser
is already deprecated, but there are some browser peculiarities which can't be solved by simple feature detection.
Seeing as $.browser
doesn't do much more than sniffing the userAgent
string with some regexes and it doesn't have any external jQuery method dependency, it should still work fine in any future jQuery version without maintenance.
I hope the deprecated methods would be supplied in a CDN copy of jQuery as well, to have it already cached in the browser without generating more HTTP requests as a plugin/extension would. It's possible to remove the Deprecated methods from a custom jQuery build using the grunt command line, it shouldn't be hard to have a core build and a core+deprecated build now and in future. Anyway, even if the deprecated methods are supplied in a different JS file from a CDN, I'll be fine with that.
Changed August 22, 2012 12:42PM UTC by comment:5
Replying to [comment:2 b.n.williams@…]:
According to the jquery blog post at http://blog.jquery.com/2012/06/22/jquery-1-8-beta-1-see-whats-coming-and-going/ $.browser is going to be dropped completely. They mentioned they'll be making plugins for deprecated features such as this, but looks like it won't be released until 1.9. So I put together a plugin for now, and added support for fixing this bug (that i also ran into) https://github.com/scien/jquery.browser
There's an official back-compat plugin: https://github.com/jquery/jquery-browser
We should probably just get fixes into there instead of having the community creating their own. Otherwise, we might as well abandon the official one.
Changed August 22, 2012 01:00PM UTC by comment:6
The 1.9-compat plugin will have $.browser and include this fix, it just won't be around until 1.9 draws near.
The Google and Microsoft CDNs make their own decisions about what files to host, there is also cdnjs.com for some common and popular third-party plugins. But if you need a dozen plugins for a page you're almost always better off combining and compressing them into a single file and hosting it locally rather than including a dozen individual files from a CDN.
Agreed. Let's fix this and then never touch
$.browser
again.