Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On Thu, Jun 7, 2012 at 4:41 PM, Brendan Eich wrote: > Adam Barth wrote: >> >> On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa 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
Re: [webkit-dev] Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore
On Thu, Jun 7, 2012 at 3:43 PM, Dean Jackson wrote: > > On 07/06/2012, at 12:05 PM, Annie Sullivan 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 2:08 PM, Dean Jackson wrote: > > On 07/06/2012, at 10:07 AM, Annie Sullivan wrote: > >> Oops, forgot to reply-all. >> >> On Thu, Jun 7, 2012 at 9:05 AM, Annie Sullivan wrote: >>> On Wed, Jun 6, 2012 at 4:59 PM, Darin Adler 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
Oops, forgot to reply-all. On Thu, Jun 7, 2012 at 9:05 AM, Annie Sullivan wrote: > On Wed, Jun 6, 2012 at 4:59 PM, Darin Adler 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
[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
[webkit-dev] Storing strings in 8-bit buffers where possible
Hi webkit-dev: >From our testing, some pages (like espn.com) waste up to 3-5% of WebCore's total memory storing 8-bit-encoded strings in 16-bit buffers. We've started investigating changing our String class to store 8-bit-encoded strings in 8-bit buffers when possible (reclaiming all this wasted memory). This project is tricky because 1. JavaScript exposes the double-byte-ness of strings in the DOM and 2. our String classes tend to be very performance sensitive. We're proceeding with caution. :) If anyone would like to follow along at home, they should CC themselves on the bug: https://bugs.webkit.org/show_bug.cgi?id=66161 -Annie ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
