On 27 November 2014 at 11:39, Dmitry Lomov <dslo...@chromium.org> wrote: > On Thu, Nov 27, 2014 at 11:01 AM, Drew Wilson <atwil...@chromium.org> wrote: >> On Thu, Nov 27, 2014 at 10:35 AM, Dmitry Lomov <dslo...@chromium.org> >> wrote: >>> On Thu, Nov 27, 2014 at 10:13 AM, Drew Wilson <atwil...@chromium.org> >>> wrote: >>>> >>>> What impact do we expect on web compatibility from apps that may already >>>> be adding attributes named "include", etc to their String objects? >>>> >>>> I think that adding attributes that Firefox is already shipping should >>>> be relatively safe, but I'm very leery about being the first browser to add >>>> new attributes. What can we do to avoid a repeat of >>>> http://crbug.com/409858? >>>> Do we have any stats for how often these attributes are already in use in >>>> web pages (tricky, since some apps are legitimately using them for polyfill >>>> purposes)? >>> >>> Correct, this is tricky. We do not have stats (and it is unclear how to >>> get those stats). >>> 'contains' was renamed to 'includes' precisely to reduce possible web >>> compat breakage. >>> Unfortunately we will not know of any breakage until we ship this - it >>> has been available under a flag for some time, but it looks like nobody >>> tests with 'Experimental Javascript features' enabled. >>> Therefore enabling it early on canary in Chrome 41 process is our best >>> mitigation in this particular case. >> >> I'm not sure "let's just launch this and see who complains" is an >> acceptable path forward given that this specific approach was tried last >> release with Array.values and blew up in our face. Why do we think this time >> will be any different? >> >> Can we perhaps restrict this to canary + dev channel (and maybe the first >> beta cut), but hold off on shipping to Stable until we find a way to >> generate stats? > > Shipping this now is de facto canary + dev. > I do not know of a way to generate stats for this (unfortunately).
What Dmitry said. Of course, if problems are discovered there, then we will roll back before the next beta. But if they aren't then we have no realistic way of knowing other than shipping it in beta. That's what beta is for, after all. The good news is that after the previous incident we changed our roll-out procedure such that unshipping a feature now consists of only swapping a macro invocation. It's also worth noting that we have shipped many other new features without any problems. Array.p.values was the only exception so far. On 27 November 2014 at 11:06, PhistucK <phist...@gmail.com> wrote: > Can we add a console log (not a warning) for the canary/dev/beta run > (perhaps stable, too?) for a little while to aid developers with possible > breakages? > If String.prototype.includes is overridden, deleted or accessed (called or > gotten), the log would be printed. Unfortunately, I believe that is infeasible. As Dmitry already noted, it is not at all easy to diagnose the situation, even if you were willing to accept lots of false positives. JavaScript is far too "dynamic" (and generally broken beyond repair when it comes to robustness). Moreover, ES6 adds plenty of new methods across the board, and we wouldn't want to install a complicated mechanism like that for each and every one of them, even though a priori, there is no reason to believe that any one of them has less or more potential for breakage than A.p.includes has. /Andreas -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
