Add a string for the release channel, e.g. 'canary', 'dev', 'beta', 'stable'.
Created attachment 145858 [details] Patch
(In reply to comment #1) > Created an attachment (id=145858) [details] > Patch Work in progress. A few questions: 1) I can easily make a layout test that checks the value of navigator.channel, but the value will vary depending on how Chrome is built. Is there something better I can do than making expectations files which pass if it's defined as a string in chrome and if it's not defined in the other ports? 2) Is the approach of pulling in the release branch from the GYP files okay? The other approach I can use is calling chrome::VersionInfo::Channel() at runtime. 3) For local builds and anything else that's not an official channel, what should navigator.channel read? "unknown" like in the channel enum?
This doesn’t seem like something that should be part of WebKit. A client application should be able to use WebKit API to add this property. The right place to do this would be in the client’s didClearWindowObjectForFrame() implementation.
> This doesn’t seem like something that should be part of WebKit. A client application should be able to use WebKit API to add this property. We actually had an implementation in the client, but I asked Annie to write a patch for WebKit so that this property can live along with appCodeName and the other similar properties on Navigator. Is there a particular reason why this isn't appropriate for WebKit (as compared wit the other similar existing navigator properties)?
I don't think that there is anything specific to the property at hand, just the same reason why we are not adding functionality unique to Apple clients (like iTunes) to WebCore. While technically it's of course easier to have related properties together, I agree with Mitz that client functionality should stay out of WebCore as much as technically possible.
Your comment presupposes that this is client functionality. Why is it any more a client functionality than appCodeName?
I may be not following your line of thought, because it feels like a very clear distinction to me. Doing what every browser needs is part of WebKit project, but navigator.channel is unique to one browser based on WebKit, and is entirely meaningless to every non-chromium person working on the project.
Thanks, Alexey. I couldn’t have said it better.
> Doing what every browser needs is part of WebKit project, but navigator.channel is unique to one browser based on WebKit, and is entirely meaningless to every non-chromium person working on the project. Is that just a naming issue? Many consumers of WebKit have notions of a "beta" release of their product. The notion of a beta release is hardly Chromium-specific. For example, Safari 3 had a beta release. From an interface perspective, it seems quite analogous to appVersion.
> The notion of a beta release is hardly Chromium-specific. We have not exposed that via DOM though, and even if we did, using the name "channel" is far from a given. Yes, I agree that it's analogous - alluded to that in comment 5 too. From the perspective of a person who works on a project that exposes both navigator.appName and navigator.channel implementing them together makes a lot of sense. This is also completely alien and weird for others. In WebKit project, we've been working fairly hard on separating areas of concern, and keeping navigator.channel away from view of people who never need to hear about it just feels natural (as long as technical costs don't become exorbitant).
Do you have a suggestion for a name other than "channel"? I don't think we have any attachment to that name. I don't understand what concerns you're trying to separate. The navigator object is a web platform API for exposing information about the user agent, such as the user agent string, it's version, etc.
I don't have any better name than "channel" to expose which Chrome channel the browser came from, except for perhaps "chromeChannel". Other browsers don't come from Chrome channels, and don't expose any similar data, so renaming cannot help. I think that the existing solution with injecting the property from client code is best.
I I don't think chromeChannel is an appropriate name because this concept is not specific to Chrome. Perhaps buildType would be a better name. Firefox seems to call refer to their "beta build" and to Aurora as a "pre-beta" build. nightly.webkit.org refers to "nightly builds" and might reasonably return the string "nightly" from this API.
@ap: I don't agree that the builtType is a Chrome-specific concept. In fact, it seems to be a concept used actively by every browser (with the possible exception of Safari---which used the concept as recently as Safari 3 beta). @Annie: Would you be willing to update the patch to use the name "buildType" ? Also, rather than implementing this as a Module, it's probably better to just define the attribute in Navigator.idl and use an ENABLE macro.
> I don't agree that the builtType is a Chrome-specific concept. In fact, it seems to be a concept used actively by every browser Well, I guess you need to get support from other vendors of WebKit-based products on webkit-dev if you want this in WebCore.
Indeed. Annie, would you be willing to email webkit-dev as described in http://www.webkit.org/coding/adding-features.html ?
Created attachment 146101 [details] Patch
(In reply to comment #14) > @Annie: Would you be willing to update the patch to use the name "buildType" ? Also, rather than implementing this as a Module, it's probably better to just define the attribute in Navigator.idl and use an ENABLE macro. I updated the patch.(In reply to comment #16) > Indeed. Annie, would you be willing to email webkit-dev as described in http://www.webkit.org/coding/adding-features.html ? Done.
I think this was Chrome specific patch because I don't think Safari has this build structure and I was not able to find anything using "navigator.buildType" on Webkit GitHub and don't see this landing by searching this "88358". I am going to mark this as "RESOLVED WONTFIX", please update it, if needed.