I am the product manager for OmniWeb, a browser for Mac OS X based on the same WebCore and JavaScriptCore frameworks that Safari is based on (from KHTML and KJS).

Links:
[link]
[link]

This script (Full Featured Browser Detection PHP Script) makes some account for OmniWeb, but fails to get the correct version number and has a value of FALSE for DOM compatibility (when really our DOM is the same as Safari's).

The following are user agent strings for most released versions of OmniWeb with WebKit:

5.1 beta 1 (latest released version):
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/125.4 (KHTML, like Gecko, Safari) OmniWeb/v563.15

5.0:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/85 (KHTML, like Gecko) OmniWeb/v558.36

4.5:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/85 (KHTML, like Gecko) OmniWeb/v496


As you can see, we added the string "Safari" in the OmniWeb 5.1 release. This has helped us gain a lot of compatibility on sites where browser sniffing would often look for "Safari" instead of the Apple-recommended string of "AppleWebKit" (see [new user link]).

If this script could gain better support for OmniWeb that would be fantastic. Please let me know if you have any questions at all about this.
Back to top

Thanks for providing the navigator user agent strings, I wasn't able to dig up any so couldn't correctly support omniweb.

Generally on this script we've gone for very accurate detection of whatever user agent we can do, so that's what we'll do in this case, but of course we can't do anything about all the other scripts out there that will either id this as gecko or safari.

check back tonite, once the version number is updated the omniweb detection will be corrected.

thanks for the headsup on this, we try to cover every browser that is actually in use, but of course it's impossible to get all of them, especially the mac ones.

I hadn't followed omniweb for a while, I forgot it was using the khtml core, had it in the script notes but forgot that.

Once updated, it will id as omniweb, but I'll add a switch in the main script where that can be changed to safari depending on user preference.
Back to top

That is now fixed:

You now have two options:
Standard is straight omniweb detection. No modification necessary.
Custom requires a simple change in the code: search for:
case 'omni':
in the script, uncomment that case block, and the script will return the KHTML/Safari id, with the right AppleWebKit version number.

This new detection is available in 4.9.4

The browser number with a non-numeric element, 'v' in this case, was the cause of main version number detection failure.

While technically I think I'd agree with your developer page that users should detect for safari/applewebkit, many people who use this script use it to do things like 'you are using browser x or y' etc, so we left the omniweb detection as default, and offer an option to switch on omniweb=safari detection, which then automatically turns off omniweb detection. Maybe we'll make a change and offer the applewebkit option too in later releases, but it's actually slightly difficult to implement with the current logic, although we do something similar with gecko detection, which is something I'm more involved in currently personally, see how your market share goes ; - )

Currently, with this change it's a fairly trivial matter to pick:



not that hard to do, easier than adding a whole new module to the thing, which is already way too big for what it does, need to rewrite parts of it, due on version 5.0.0, which is getting further away currently, we'll see.
Back to top

Excellent, thank you!



I understand your position here. However, more and more applications on the Mac are integrating AppleWebKit for browsing functionality. There are a few sort of specialized browsers available, a couple of fairly full-featured browsers, and a slew of other applications like RSS news readers that are using these frameworks and are just as capable as Safari or OmniWeb.

I tried to get into your script to modify things myself, but to be honest it's beyond me at this point. It seems thought that it wouldn't be too terribly hard to do a generic AppleWebKit test before or after testing for OmniWeb and Safari specifically. The code shouldn't have to be as complex as the gecko stuff. From what I can tell, all these other user-agents use strings very similar to Safari itself but with a different product name at the end. All of them specify AppleWebKit with the version number in the very same format.


In any case, I really appreciate you adding OmniWeb support, and so quickly! Thanks for a great script.
Back to top

Hey, thanks.

I hadn't considered the applewebkit thing when I wrote this, but since it looks like awk is going the same direction as gecko, a universal rendering engine for different apps, I'll have to rewrite the primary modules to treat webkit more or less as I do gecko, in other words, provide a primary id option like I do with gecko/moz, then do sub-detection for various versions, and give the option in the script which to use.

This will break the browser == 'saf' detection however, but I already realized that on another site where I use that detection to support a KHTML bug it won't work on other awk systems, so I'm going to change it to work like moz detection currently works.



Unfortunately this isn't the case, the script relies on a cascade down the array of browsers to know where to stop, it's how it gets safari and opera correctly, for example, it breaks on detection. Rather than add in another whole hack section, I think it will make sense to just modularize the script more, that's been on the agenda for a while now, ideally one module can do all the subversion detection stuff for os and browsers.

If you take a closer look you'll see that I use more or less the same methods in gecko subversion and linux/unix subversion detection, detect primary identifier, then do the sub detection on that primary identifier, that works very well.

That was redone to better support the mozdev site, specifically to support the various alpha and beta firefoxes, I don't know if they are still using it, but they were at one point.

The problem I have is that I try to keep this script completely backward compatible, so people can just update the script without having to redo their on page useage of the script calls, so changing to a default 'webkit' type id with sub id options would involve a change in the script function parameters used, I 've only changed this one time before, when I added full netscape < 5 detection, but I think I'll have to do it.

However, I won't have time this month, I think I'll add that to my 5.0.0 todo list though.

Consider the 4.9.4 a temporary hack, I'll get the real fix up as soon as I get time.



I know, it's gotten very complicated, that's one reason I'm going to try to simplify the logic a tiny bit, not much, getting it to catch different versions of different nua strings is not easy, it's too big for my taste right now, but it works really well.

Another thing I have to add is support for those stupid Windows IE shells like crazy browser, it will make sense to just create another function for sub detection and clean out the primary function a bit.

======================

We have to be a bit careful, before I got the useragent switcher extension for firefox, this stuff wasn't tested well enough, and there was at 2 points serious bugs, one with unix/search spider and one with os x detection, that would cause a full page rendering failure, luckily we caught that, but not before a lot of the scripts had been implemented, so we try to be more careful now with changes.
Back to top

I finally got around to doing a full webkit hander.

See php browser detection 4.10.x

There are now so many webkit browsers out there that it was worth redoing the logic.

And it was quite simple, now for primary browser type webkit, you get returned the browser name string (omniweb, iphone, safari, epiphany, chrome, etc)

Just wanted to update this thread to let anyone know who needs this information.
Back to top