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.

Reply via email to