Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#7696 closed defect (fixed)

dojo.isChrome and dojo.isWebKit

Reported by: James Burke Owned by: James Burke
Priority: high Milestone: 1.3
Component: Core Version: 1.2beta
Keywords: Cc:
Blocked By: Blocking:


Just as we do for mozilla vs. firefox, provide a dojo.isWebKit and a dojo.isChrome for Google Chrome. Be sure dojo.isSafari fits with the model.

Change History (4)

comment:1 Changed 14 years ago by James Burke

Resolution: fixed
Status: newclosed

(In [15430]) Fixes #5574 and Fixes #7696. dojo.isChrome and dojo.isWebKit available. dojo.isWebKit now gives version numbers like 525.3. KHTML detection changed to just support being defined for KHTML browsers only, since other KHTML-related browsers are likely more sensitive to dojo.isWebKit versions. Changed dojo.isSafari check so that now Safari 3.1.2 now correctly reports as dojo.isSafari 3.1. But with that change, Chrome browser does not have dojo.isSafari defined, which should be good, since we now have dojo.isWebKit and then dojo.isChrome for chrome-specific (non-webkit) issues. Now that there are webkit numbers, switched to DOMContentLoaded for webkit versions that support it. \!strict

comment:2 Changed 14 years ago by Adam Peller

Aren't KHTML and Webkit codebases independent? I think the webkit UA references KHTML as a historical artifact, but not vice-versa.

comment:3 Changed 14 years ago by James Burke

I think KHTML was considering adopting the webkit codebase, but I believe historically, they have been different, related codebases, so I do not think the change I did to KTHML detection is bad.

comment:4 Changed 14 years ago by Adam Peller

agreed. The change is fine. I think we just need to reconcile the inline docs.

Note: See TracTickets for help on using tickets.