This is to ease debugging, not to solve every single case. As much as possible, log it. On a 'best available' case.
☆*PhistucK* On Thu, Nov 27, 2014 at 1:14 PM, 'Andreas Rossberg' via blink-dev < blink-...@chromium.org> wrote: > 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 > > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > -- -- 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.