#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: |
Description
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 13 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:2 Changed 12 years ago by
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 12 years ago by
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 12 years ago by
agreed. The change is fine. I think we just need to reconcile the inline docs.
Note: See
TracTickets for help on using
tickets.
(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