Bug 88358 – Add navigator.buildType to indiciate the type of build (e.g., nightly, beta, final)

• Component: New Bugs
• Status: RESOLVED WONTFIX

[Annie Sullivan]

Add a string for the release channel, e.g. 'canary', 'dev', 'beta', 'stable'.

[Annie Sullivan]

Created attachment 145858 [details]
Patch

[Annie Sullivan]

(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.

[Adam Barth]

> 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)?

[Alexey Proskuryakov]

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.

[Adam Barth]

Your comment presupposes that this is client functionality.  Why is it any more a client functionality than appCodeName?

[Alexey Proskuryakov]

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.

[Adam Barth]

> 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.

[Alexey Proskuryakov]

> 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).

[Adam Barth]

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.

[Alexey Proskuryakov]

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.

[Adam Barth]

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.

[Adam Barth]

@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.

[Alexey Proskuryakov]

> 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.

[Adam Barth]

Indeed.  Annie, would you be willing to email webkit-dev as described in http://www.webkit.org/coding/adding-features.html ?

[Annie Sullivan]

Created attachment 146101 [details]
Patch

[Annie Sullivan]

(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.

[Ahmad Saleem]

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.