Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
Oops, forgot to reply-all. On Thu, Jun 7, 2012 at 9:05 AM, Annie Sullivan sulli...@chromium.org wrote: On Wed, Jun 6, 2012 at 4:59 PM, Darin Adler da...@apple.com wrote: Our past experience with this sort of thing at Apple is that it led to bugs we didn’t find until after we shipped “final” software because they did not show up during earlier testing. Since then, we’ve gone out of our way to avoid differences, since one of the main things we want to do with non-final builds is to approximate the final releases as closely as possible to get useful testing. To oversimplify, website developers notoriously make mistakes with these types of attributes doing things like version and OS checks, leading to website incompatibilities. Yes, this is definitely a concern we have as well. Maybe you could make your case for the usefulness of the attribute? The problem we're experiencing in Chrome is for sites that collect usage data--it turns out there's a selection bias caused by users who opt in to our canary, dev, and beta channels. The specific case I'm looking at right now is sites collecting performance data from their user base. We'd love for these sites to be able to report regressions they see in Chrome's performance as early as possible. But it turns out users on different channels actually show different performance characteristics. Beta users seem to have faster machines, for example. So in order to compare two versions of Chrome, we need to compare data from users on the same release channel. So we'd like sites who collect performance information to be able to collect the build type in order to do that comparison. We considered a few alternatives: 1) Adding a marker in the user agent string that indicates the channel. The problem with this is that there is a lot of very fragile code in the wild which parses user agent strings and breaks at the slightest change. For example, code that parses Opera 10 as Opera 1. 2) Updating the version number as Chrome advances from canary to dev to beta to stable, or encoding the build type in one of the octets of the version number. The problem with this is that there's a big possibility of sites that do version checking accidentally turning off features on some channels. There are also a lot of things that we *do* want to track across release channels for a specific version, like bugs. So changing the version number could cause confusion there. 3) Sending an x-buildtype header. If we do this on every request, it's a lot of bloat. We can't restrict it to requests that send a corresponding x-tell-me-the-buildtype request header because most metrics collection libraries send their metrics in an image request, so they can't send custom headers. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On 07/06/2012, at 10:07 AM, Annie Sullivan sulli...@chromium.org wrote: Oops, forgot to reply-all. On Thu, Jun 7, 2012 at 9:05 AM, Annie Sullivan sulli...@chromium.org wrote: On Wed, Jun 6, 2012 at 4:59 PM, Darin Adler da...@apple.com wrote: Our past experience with this sort of thing at Apple is that it led to bugs we didn’t find until after we shipped “final” software because they did not show up during earlier testing. Since then, we’ve gone out of our way to avoid differences, since one of the main things we want to do with non-final builds is to approximate the final releases as closely as possible to get useful testing. To oversimplify, website developers notoriously make mistakes with these types of attributes doing things like version and OS checks, leading to website incompatibilities. Yes, this is definitely a concern we have as well. Maybe you could make your case for the usefulness of the attribute? The problem we're experiencing in Chrome is for sites that collect usage data--it turns out there's a selection bias caused by users who opt in to our canary, dev, and beta channels. The specific case I'm looking at right now is sites collecting performance data from their user base. We'd love for these sites to be able to report regressions they see in Chrome's performance as early as possible. But it turns out users on different channels actually show different performance characteristics. Beta users seem to have faster machines, for example. So in order to compare two versions of Chrome, we need to compare data from users on the same release channel. So we'd like sites who collect performance information to be able to collect the build type in order to do that comparison. We considered a few alternatives: 1) Adding a marker in the user agent string that indicates the channel. The problem with this is that there is a lot of very fragile code in the wild which parses user agent strings and breaks at the slightest change. For example, code that parses Opera 10 as Opera 1. 2) Updating the version number as Chrome advances from canary to dev to beta to stable, or encoding the build type in one of the octets of the version number. The problem with this is that there's a big possibility of sites that do version checking accidentally turning off features on some channels. There are also a lot of things that we *do* want to track across release channels for a specific version, like bugs. So changing the version number could cause confusion there. 3) Sending an x-buildtype header. If we do this on every request, it's a lot of bloat. We can't restrict it to requests that send a corresponding x-tell-me-the-buildtype request header because most metrics collection libraries send their metrics in an image request, so they can't send custom headers. navigator.buildType might address your particular problem, but introduces a significant risk of future issues. I can imagine keen web authors adding features based on detecting nightly or beta that then break in final. This is similar to prefixing CSS properties which, as you probably know, is an extremely hot discussion topic right now in the community. I don't think people will be especially excited for another potential point of failure. Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
07.06.2012, 21:07, Annie Sullivan sulli...@chromium.org: Oops, forgot to reply-all. On Thu, Jun 7, 2012 at 9:05 AM, Annie Sullivan sulli...@chromium.org wrote: On Wed, Jun 6, 2012 at 4:59 PM, Darin Adler da...@apple.com wrote: Our past experience with this sort of thing at Apple is that it led to bugs we didn’t find until after we shipped “final” software because they did not show up during earlier testing. Since then, we’ve gone out of our way to avoid differences, since one of the main things we want to do with non-final builds is to approximate the final releases as closely as possible to get useful testing. To oversimplify, website developers notoriously make mistakes with these types of attributes doing things like version and OS checks, leading to website incompatibilities. Yes, this is definitely a concern we have as well. Maybe you could make your case for the usefulness of the attribute? The problem we're experiencing in Chrome is for sites that collect usage data--it turns out there's a selection bias caused by users who opt in to our canary, dev, and beta channels. The specific case I'm looking at right now is sites collecting performance data from their user base. We'd love for these sites to be able to report regressions they see in Chrome's performance as early as possible. But it turns out users on different channels actually show different performance characteristics. Beta users seem to have faster machines, for example. Are you sure that this differences are statistically significant? So in order to compare two versions of Chrome, we need to compare data from users on the same release channel. So we'd like sites who collect performance information to be able to collect the build type in order to do that comparison. We considered a few alternatives: 1) Adding a marker in the user agent string that indicates the channel. The problem with this is that there is a lot of very fragile code in the wild which parses user agent strings and breaks at the slightest change. For example, code that parses Opera 10 as Opera 1. 2) Updating the version number as Chrome advances from canary to dev to beta to stable, or encoding the build type in one of the octets of the version number. The problem with this is that there's a big possibility of sites that do version checking accidentally turning off features on some channels. There are also a lot of things that we *do* want to track across release channels for a specific version, like bugs. So changing the version number could cause confusion there. 3) Sending an x-buildtype header. If we do this on every request, it's a lot of bloat. We can't restrict it to requests that send a corresponding x-tell-me-the-buildtype request header because most metrics collection libraries send their metrics in an image request, so they can't send custom headers. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On Thu, Jun 7, 2012 at 11:48 AM, Konstantin Tokarev annu...@yandex.ru wrote: 07.06.2012, 21:07, Annie Sullivan sulli...@chromium.org: Oops, forgot to reply-all. On Thu, Jun 7, 2012 at 9:05 AM, Annie Sullivan sulli...@chromium.org wrote: On Wed, Jun 6, 2012 at 4:59 PM, Darin Adler da...@apple.com wrote: Our past experience with this sort of thing at Apple is that it led to bugs we didn't find until after we shipped final software because they did not show up during earlier testing. Since then, we've gone out of our way to avoid differences, since one of the main things we want to do with non-final builds is to approximate the final releases as closely as possible to get useful testing. To oversimplify, website developers notoriously make mistakes with these types of attributes doing things like version and OS checks, leading to website incompatibilities. Yes, this is definitely a concern we have as well. Maybe you could make your case for the usefulness of the attribute? The problem we're experiencing in Chrome is for sites that collect usage data--it turns out there's a selection bias caused by users who opt in to our canary, dev, and beta channels. The specific case I'm looking at right now is sites collecting performance data from their user base. We'd love for these sites to be able to report regressions they see in Chrome's performance as early as possible. But it turns out users on different channels actually show different performance characteristics. Beta users seem to have faster machines, for example. Are you sure that this differences are statistically significant? Yes. Adam So in order to compare two versions of Chrome, we need to compare data from users on the same release channel. So we'd like sites who collect performance information to be able to collect the build type in order to do that comparison. We considered a few alternatives: 1) Adding a marker in the user agent string that indicates the channel. The problem with this is that there is a lot of very fragile code in the wild which parses user agent strings and breaks at the slightest change. For example, code that parses Opera 10 as Opera 1. 2) Updating the version number as Chrome advances from canary to dev to beta to stable, or encoding the build type in one of the octets of the version number. The problem with this is that there's a big possibility of sites that do version checking accidentally turning off features on some channels. There are also a lot of things that we *do* want to track across release channels for a specific version, like bugs. So changing the version number could cause confusion there. 3) Sending an x-buildtype header. If we do this on every request, it's a lot of bloat. We can't restrict it to requests that send a corresponding x-tell-me-the-buildtype request header because most metrics collection libraries send their metrics in an image request, so they can't send custom headers. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On Thu, Jun 7, 2012 at 2:08 PM, Dean Jackson d...@apple.com wrote: On 07/06/2012, at 10:07 AM, Annie Sullivan sulli...@chromium.org wrote: Oops, forgot to reply-all. On Thu, Jun 7, 2012 at 9:05 AM, Annie Sullivan sulli...@chromium.org wrote: On Wed, Jun 6, 2012 at 4:59 PM, Darin Adler da...@apple.com wrote: Our past experience with this sort of thing at Apple is that it led to bugs we didn’t find until after we shipped “final” software because they did not show up during earlier testing. Since then, we’ve gone out of our way to avoid differences, since one of the main things we want to do with non-final builds is to approximate the final releases as closely as possible to get useful testing. To oversimplify, website developers notoriously make mistakes with these types of attributes doing things like version and OS checks, leading to website incompatibilities. Yes, this is definitely a concern we have as well. Maybe you could make your case for the usefulness of the attribute? The problem we're experiencing in Chrome is for sites that collect usage data--it turns out there's a selection bias caused by users who opt in to our canary, dev, and beta channels. The specific case I'm looking at right now is sites collecting performance data from their user base. We'd love for these sites to be able to report regressions they see in Chrome's performance as early as possible. But it turns out users on different channels actually show different performance characteristics. Beta users seem to have faster machines, for example. So in order to compare two versions of Chrome, we need to compare data from users on the same release channel. So we'd like sites who collect performance information to be able to collect the build type in order to do that comparison. We considered a few alternatives: 1) Adding a marker in the user agent string that indicates the channel. The problem with this is that there is a lot of very fragile code in the wild which parses user agent strings and breaks at the slightest change. For example, code that parses Opera 10 as Opera 1. 2) Updating the version number as Chrome advances from canary to dev to beta to stable, or encoding the build type in one of the octets of the version number. The problem with this is that there's a big possibility of sites that do version checking accidentally turning off features on some channels. There are also a lot of things that we *do* want to track across release channels for a specific version, like bugs. So changing the version number could cause confusion there. 3) Sending an x-buildtype header. If we do this on every request, it's a lot of bloat. We can't restrict it to requests that send a corresponding x-tell-me-the-buildtype request header because most metrics collection libraries send their metrics in an image request, so they can't send custom headers. navigator.buildType might address your particular problem, but introduces a significant risk of future issues. I can imagine keen web authors adding features based on detecting nightly or beta that then break in final. This is similar to prefixing CSS properties which, as you probably know, is an extremely hot discussion topic right now in the community. I don't think people will be especially excited for another potential point of failure. I think this is different from CSS prefixing because of size of the potential user base involved. With CSS prefixing, on mobile phones right now web developers can reach nearly 100% of their audience with only -webkit prefixes. So they have no reason to fix their sites to drop the prefixes. With the buildType, it's pretty clear that web developers are going to reach only a small percentage of their users if they check for beta or nightly. So it doesn't really make sense for them to create a site that depends on this. In many browsers in the past, it's been pretty easy to determine from a and b characters in the user agent of many browsers which builds are alpha and beta, and I haven't heard of bugs caused specifically by checking for build type there. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On Thu, Jun 7, 2012 at 3:43 PM, Dean Jackson d...@apple.com wrote: On 07/06/2012, at 12:05 PM, Annie Sullivan sulli...@chromium.org wrote: In many browsers in the past, it's been pretty easy to determine from a and b characters in the user agent of many browsers which builds are alpha and beta, and I haven't heard of bugs caused specifically by checking for build type there. So why not just do that then? While it's nice that web developers don't seem to be using the build type info in the user agent string in their code, user agent parsing code is still very brittle. Some browsers, like Firefox, have had buildtype characters in the user agent string for many years, so parsing code can handle things like Firefox/14.0a2. But Chrome hasn't ever changed its version format, so we're worried about breaking user agent parsers. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On Thu, Jun 7, 2012 at 12:53 PM, Annie Sullivan sulli...@chromium.org wrote: On Thu, Jun 7, 2012 at 3:43 PM, Dean Jackson d...@apple.com wrote: On 07/06/2012, at 12:05 PM, Annie Sullivan sulli...@chromium.org wrote: In many browsers in the past, it's been pretty easy to determine from a and b characters in the user agent of many browsers which builds are alpha and beta, and I haven't heard of bugs caused specifically by checking for build type there. So why not just do that then? While it's nice that web developers don't seem to be using the build type info in the user agent string in their code, user agent parsing code is still very brittle. Some browsers, like Firefox, have had buildtype characters in the user agent string for many years, so parsing code can handle things like Firefox/14.0a2. But Chrome hasn't ever changed its version format, so we're worried about breaking user agent parsers. Even beyond that, putting the buildType in the User-Agent seems strictly worse that exposing it as a separate property to JavaScript. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan sulli...@chromium.orgwrote: I wanted to let you know that I plan to add support for navigator.buildType (e.g., nightly, beta, final) to WebKit. This feature isn't on the standards track (but neither are a bunch of other similar properties on Navigator). This feature will be behind the ENABLE(NAVIGATOR_BUILDTYPE) feature define. See: https://bugs.webkit.org/show_bug.cgi?id=88358 http://html.spec.whatwg.org/#navigator What is the rationale for adding this property on the navigator object instead of the chrome object we also expose if your'e not expecting this property to be ever standarized? The feedback the WebKit community at large has given us so far appears to be strictly negative about adding this to the navigator object. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan sulli...@chromium.org wrote: I wanted to let you know that I plan to add support for navigator.buildType (e.g., nightly, beta, final) to WebKit. This feature isn't on the standards track (but neither are a bunch of other similar properties on Navigator). This feature will be behind the ENABLE(NAVIGATOR_BUILDTYPE) feature define. See: https://bugs.webkit.org/show_bug.cgi?id=88358 http://html.spec.whatwg.org/#navigator What is the rationale for adding this property on the navigator object instead of the chrome object we also expose if your'e not expecting this property to be ever standarized? Generally, we avoid implementing web visible features via the chrome object because that makes them Chrome-proprietary. In this case, it seems entirely reasonable for other browsers (e.g., Firefox) to want to implement this feature. By putting it on navigator, we invite them to implement it as well. The feedback the WebKit community at large has given us so far appears to be strictly negative about adding this to the navigator object. The mechanism for implementing the feature doesn't really affect the arguments that folks are making on this thread. If we decide that the feature is worth implementing, we should implement it on navigator. If the feature is not worth implementing, we shouldn't implement it on the chrome object either. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On 07/06/2012, at 12:53 PM, Annie Sullivan sulli...@chromium.org wrote: On Thu, Jun 7, 2012 at 3:43 PM, Dean Jackson d...@apple.com wrote: On 07/06/2012, at 12:05 PM, Annie Sullivan sulli...@chromium.org wrote: In many browsers in the past, it's been pretty easy to determine from a and b characters in the user agent of many browsers which builds are alpha and beta, and I haven't heard of bugs caused specifically by checking for build type there. So why not just do that then? While it's nice that web developers don't seem to be using the build type info in the user agent string in their code, user agent parsing code is still very brittle. Some browsers, like Firefox, have had buildtype characters in the user agent string for many years, so parsing code can handle things like Firefox/14.0a2. But Chrome hasn't ever changed its version format, so we're worried about breaking user agent parsers. Right, I understand that issue. But I don't think replacing something flakey and problematic with something that could be equally flakey and problematic is a big win. Your original problem was: We'd love for these sites to be able to report regressions they see in Chrome's performance as early as possible. But it turns out users on different channels actually show different performance characteristics. Beta users seem to have faster machines, for example. So in order to compare two versions of Chrome, we need to compare data from users on the same release channel. So we'd like sites who collect performance information to be able to collect the build type in order to do that comparison. That sounds exactly like User Agent detection to me. You want to detect build version and type. I still think there are similarities to prefixing. The Web community (not just WebKit) is making a lot of noise about how being able to detect browsers might seem like a good idea at first but ends up causing longer-term headaches. By the way, I don't feel strongly about this. I'm just pointing out that I don't see any benefit and that what looks like a small change in metadata has just as important consequences as a significant technical change. Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On 07/06/2012, at 1:10 PM, Adam Barth aba...@webkit.org wrote: On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan sulli...@chromium.org wrote: I wanted to let you know that I plan to add support for navigator.buildType (e.g., nightly, beta, final) to WebKit. This feature isn't on the standards track (but neither are a bunch of other similar properties on Navigator). This feature will be behind the ENABLE(NAVIGATOR_BUILDTYPE) feature define. See: https://bugs.webkit.org/show_bug.cgi?id=88358 http://html.spec.whatwg.org/#navigator What is the rationale for adding this property on the navigator object instead of the chrome object we also expose if your'e not expecting this property to be ever standarized? Generally, we avoid implementing web visible features via the chrome object because that makes them Chrome-proprietary. In this case, it seems entirely reasonable for other browsers (e.g., Firefox) to want to implement this feature. By putting it on navigator, we invite them to implement it as well. But the original message said: I wanted to let you know that I plan to add support for navigator.buildType (e.g., nightly, beta, final) to WebKit. This feature isn't on the standards track (but neither are a bunch of other similar properties on Navigator) If you don't want it to be Chrome or WebKit-proprietary, and you're inviting other browsers to implement it, then you should probably speak to them and the rest of the community up front. It definitely would be much nicer if User Agent was exposed as a bunch of neatly organised JavaScript properties on the navigator object. Of course then we'd eventually have issues similar to what are now parsing errors. Who says a browser won't want to add alpha or release-candidate to the list above. This is going to be flakey no matter what. I should stop replying now because I really don't care anywhere near as much about this as I'm suggesting by all my email :) Dean The feedback the WebKit community at large has given us so far appears to be strictly negative about adding this to the navigator object. The mechanism for implementing the feature doesn't really affect the arguments that folks are making on this thread. If we decide that the feature is worth implementing, we should implement it on navigator. If the feature is not worth implementing, we shouldn't implement it on the chrome object either. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
Adam Barth wrote: On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwarn...@webkit.org wrote: What is the rationale for adding this property on the navigator object instead of the chrome object we also expose if your'e not expecting this property to be ever standarized? Generally, we avoid implementing web visible features via the chrome object because that makes them Chrome-proprietary. In this case, it seems entirely reasonable for other browsers (e.g., Firefox) to want to implement this feature. By putting it on navigator, we invite them to implement it as well. No, that's not how you invite someone to do something, in conventional human-to-human interactions :-|. It's a bit aggro -- if it makes a de-facto standard, others will follow whether they like it or not. If it has undesirable unintended consequences, too bad. As Dean pointed out, it also contradicts the pitch in Annie's first message. As Annie noted, we don't feel the need since our UA string has some [ab] cruft in it at the end, and a number after the letter that's important. But UA groveling sucks. Could we instead discuss navigator.buildType in some appropriate W3C or WHATWG list? /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On Thu, Jun 7, 2012 at 4:41 PM, Brendan Eich bren...@mozilla.org wrote: Adam Barth wrote: On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwarn...@webkit.org wrote: What is the rationale for adding this property on the navigator object instead of the chrome object we also expose if your'e not expecting this property to be ever standarized? Generally, we avoid implementing web visible features via the chrome object because that makes them Chrome-proprietary. In this case, it seems entirely reasonable for other browsers (e.g., Firefox) to want to implement this feature. By putting it on navigator, we invite them to implement it as well. No, that's not how you invite someone to do something, in conventional human-to-human interactions :-|. It's a bit aggro -- if it makes a de-facto standard, others will follow whether they like it or not. If it has undesirable unintended consequences, too bad. As Dean pointed out, it also contradicts the pitch in Annie's first message. As Annie noted, we don't feel the need since our UA string has some [ab] cruft in it at the end, and a number after the letter that's important. But UA groveling sucks. Could we instead discuss navigator.buildType in some appropriate W3C or WHATWG list? Thanks everybody for your feedback! It sounds like we need to think a bit more about the use case and whether there's a better approach we can take. We'll send an updated proposal to the whatwg list after we've thought about it a bit more. -Annie ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
Hi webkit-dev! I wanted to let you know that I plan to add support for navigator.buildType (e.g., nightly, beta, final) to WebKit. This feature isn't on the standards track (but neither are a bunch of other similar properties on Navigator). This feature will be behind the ENABLE(NAVIGATOR_BUILDTYPE) feature define. See: https://bugs.webkit.org/show_bug.cgi?id=88358 http://html.spec.whatwg.org/#navigator Looking forward to your comments. -Annie ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
Our past experience with this sort of thing at Apple is that it led to bugs we didn’t find until after we shipped “final” software because they did not show up during earlier testing. Since then, we’ve gone out of our way to avoid differences, since one of the main things we want to do with non-final builds is to approximate the final releases as closely as possible to get useful testing. To oversimplify, website developers notoriously make mistakes with these types of attributes doing things like version and OS checks, leading to website incompatibilities. Maybe you could make your case for the usefulness of the attribute? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
