On Thu, Nov 27, 2014 at 12:37 PM, PhistucK <phist...@gmail.com> wrote:
> This is to ease debugging, not to solve every single case. As much as > possible, log it. On a 'best available' case. > Logging would be prohibitively expensive as well, and lead to too many false positives. We will have to log, for example, every time somebody does an "'includes' in obj". > > > ☆*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. > -- -- 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.
