WordPress.org
Get WordPress

Make WordPress Core

Opened 14 years ago

Closed 9 years ago

Last modified 9 years ago

#18281 closed defect (bug) (duplicate)

Browse Happy API detection bugs

Reported by: nacin's profile nacin Owned by: nacin's profile nacin
Milestone: Priority: normal
Severity: normal Version:
Component: WordPress.org Site Keywords: has-patch
Focuses: Cc:

Description (last modified by nacin)

A few bugs we've noticed with the Browse Happy API so far:

  1. Mobile versions need to be labeled as such. Specifically, Mobile Safari, Opera Mini, and the Galaxy tablet, I believe. This should mean that the browser doesn't match with our list of five.
  1. For IE, we need to be looking at the Trident version numbers. Problem is, IE9 might be using a compatibility UA, which means it would get identified as IE7. Trident/5.0 is IE9, Trident/4.0 is using IE8.

I think the architecture of the API code needs some love. It served its purpose, but it's a bit inflexible for expansion. (See the Kindle hack and such.)

I'm going to open source this code onto ​http://code.svn.wordpress.org. It would be fantastic if some people can contribute to it and make it the best possible.

Attachments (3)

ios_safari.jpg​ (109.0 KB) - added by MattyRob 14 years ago.
18281.diff​ (19.6 KB) - added by aaroncampbell 14 years ago.
18281.2.diff​ (19.6 KB) - added by aaroncampbell 14 years ago.

Download all attachments as: .zip

Change History (23)

#1 @nacin
14 years ago

  • Description modified (diff)

#2 @aaroncampbell
14 years ago

Huge +1 on a revamp and getting some more people involved. There's GOT to be a better way to do this, I just didn't see one at the time.

#4 @maxcutler
14 years ago

Regarding IE9 masquerading as IE7, perhaps you can add X-UA-Compatible meta tag to WordPress header to disable compatibility mode: ​http://msdn.microsoft.com/en-us/library/cc288325.aspx

#5 @nacin
14 years ago

We *should* be okay with <!doctype html> in 3.3, according to that document, but it's unclear. But forcing X-UA-Compatible to "edge" might not be a bad idea.

#6 @aaroncampbell
14 years ago

​Awstats is GPL. I wonder if we could port their browser detection code to php? Alternatively We might be able to convert the API to perl, but then we have a bunch of PHP coders, it seems a waste to not be able to use them.

Relevant files that I saw on first pass:

#7 @MattyRob
14 years ago

Not sure if this scenario is covered by this ticket or if I need to open a new one, but...

On the latest release of Apple's iOS on my iPod Touch I get a browser nag telling me Safari is out of date. I am up to date though! Screen shot to follow.

@MattyRob
14 years ago

@aaroncampbell
14 years ago

#8 @aaroncampbell
14 years ago

  • Keywords has-patch added
  • Did away with platform (always returns empty string)
  • No longer try to match browsers we don't support - cut out early in these cases when possible (like mobile browsers)
  • Handles "insecure" for all 5 browsers
  • Still passes all the tests, but there are only 47 of them now...we need more

@aaroncampbell
14 years ago

#9 @aaroncampbell
14 years ago

18281.2.diff​ fixes the spaces in tests.php and uses require dirname(__FILE__)

#10 follow-up: @dd32
13 years ago

Chromium is being detected as an old version of Chrome apparently.

As reported by Koffa in #wordpress, the User agent in question is:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.30 (KHTML, like Gecko) Ubuntu/11.04 Chromium/12.0.742.112 Chrome/12.0.742.112 Safari/534.30

#11 in reply to: ↑ 10 @duck_
13 years ago

Replying to dd32:

Chromium is being detected as an old version of Chrome apparently.

Latest stable Chromium on Linux is 14.0.835.186 (​http://www.chromium.org/developers/calendar). It's just that Ubuntu isn't updating their Chromium package (​http://packages.ubuntu.com/natty/chromium-browser) so Koffa isn't actually running the latest Chromium -- the same happened to me, switch to the PPA provided by the Chromium team ​https://launchpad.net/chromium-project.

#12 @dd32
13 years ago

Latest stable Chromium on Linux is 14.0.835.186

Cheers, I've passed that on, only other point was it being detected as Chrome and being directed to Googles chrome page.

#13 @aaroncampbell
13 years ago

Actually we aren't supposed to be doing anything with Chromium, only Chrome. I know that we re-write the API at WCSF but I'm not sure it ever went live on .org. I don't think the new version will do ANYTHING with Chromium, but if it does we need to fix it.

#15 @Otto42
12 years ago

  • Milestone WordPress.org deleted
  • Resolution set to maybelater
  • Status changed from new to closed

If there any further specific issues with Browse Happy or the API, they should be taken to the meta.trac.

Closing this in favor of making individual tickets on the topic there.

#16 @nacin
12 years ago

  • Milestone set to WordPress.org
  • Resolution maybelater deleted
  • Status changed from closed to reopened

Re-opening as a lot of this still needs to be addressed.

#17 @nacin
12 years ago

  • Owner set to nacin
  • Status changed from reopened to accepted

#18 @chriscct7
10 years ago

Any update @nacin?

#19 @chriscct7
9 years ago

  • Keywords has-patch removed
  • Milestone WordPress.org deleted
  • Resolution set to invalid
  • Status changed from accepted to closed

Migrated to meta trac in ​https://meta.trac.wordpress.org/ticket/1303#ticket per comment:15.

#20 @SergeyBiryukov
9 years ago

  • Keywords has-patch added
  • Resolution changed from invalid to duplicate
Note: See TracTickets for help on using tickets.