[v8-users] Re: [blink-dev] Intent to ship: ES6 String functions
Resending to v8-users since apparently I didn't have permission to post previously. 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)? On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org wrote: [FYI +blink-dev] ES6 extends String.prototype with several methods: repeat, startsWith, endsWith, includes, codePointAt) and adds String.fromCodePoint method. Firefox ships codePointAt and fromCodePoint since release 29 [1], startsWith and endsWith since release 17 [2], and repeat since release 24 [3]. 'include' was previously named 'contains' and has been renamed at the last TC39 meeting. Firefox shipped 'contains' since release 17. These methods has been available under a flag for a while, and were staged in Chrome 40. [1] https://developer.mozilla.org/en-US/Firefox/Releases/29 [2] https://developer.mozilla.org/en-US/Firefox/Releases/17 [3] https://developer.mozilla.org/en-US/Firefox/Releases/24 Owners: yang...@chromium.org, dslo...@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] Re: [blink-dev] Intent to ship: ES6 String functions
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. Going forward, we have recently changed the definition of 'Experimental Javascript fetaures' in Chrome to mean 'enable staged features' (per our process https://developers.google.com/v8/launchprocess). This means that this flag really enables only those features that we consider quite mature, in particular they are expected to be stable and implementation of them must be complete. With that, we plan to evangelize enabling this flag among the power users, so that we hear about any breakage early. Dmitry On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org wrote: [FYI +blink-dev] ES6 extends String.prototype with several methods: repeat, startsWith, endsWith, includes, codePointAt) and adds String.fromCodePoint method. Firefox ships codePointAt and fromCodePoint since release 29 [1], startsWith and endsWith since release 17 [2], and repeat since release 24 [3]. 'include' was previously named 'contains' and has been renamed at the last TC39 meeting. Firefox shipped 'contains' since release 17. These methods has been available under a flag for a while, and were staged in Chrome 40. [1] https://developer.mozilla.org/en-US/Firefox/Releases/29 [2] https://developer.mozilla.org/en-US/Firefox/Releases/17 [3] https://developer.mozilla.org/en-US/Firefox/Releases/24 Owners: yang...@chromium.org, dslo...@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] Re: [blink-dev] Intent to ship: ES6 String functions
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? Just making this change with no stats around conflicts would be like the blink team deprecating an API without first measuring how often it's used. Going forward, we have recently changed the definition of 'Experimental Javascript fetaures' in Chrome to mean 'enable staged features' (per our process https://developers.google.com/v8/launchprocess). This means that this flag really enables only those features that we consider quite mature, in particular they are expected to be stable and implementation of them must be complete. With that, we plan to evangelize enabling this flag among the power users, so that we hear about any breakage early. Can we set enable staged features for the Dev channel by default to increase usage? I don't actually think this will solve the problem since experience has shown us that not enough users run on that channel to catch all of the incompatibility issues, but at least it's a start. Dmitry On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org wrote: [FYI +blink-dev] ES6 extends String.prototype with several methods: repeat, startsWith, endsWith, includes, codePointAt) and adds String.fromCodePoint method. Firefox ships codePointAt and fromCodePoint since release 29 [1], startsWith and endsWith since release 17 [2], and repeat since release 24 [3]. 'include' was previously named 'contains' and has been renamed at the last TC39 meeting. Firefox shipped 'contains' since release 17. These methods has been available under a flag for a while, and were staged in Chrome 40. [1] https://developer.mozilla.org/en-US/Firefox/Releases/29 [2] https://developer.mozilla.org/en-US/Firefox/Releases/17 [3] https://developer.mozilla.org/en-US/Firefox/Releases/24 Owners: yang...@chromium.org, dslo...@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] Re: [blink-dev] Intent to ship: ES6 String functions
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. ☆*PhistucK* On Thu, Nov 27, 2014 at 12:01 PM, 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? Just making this change with no stats around conflicts would be like the blink team deprecating an API without first measuring how often it's used. Going forward, we have recently changed the definition of 'Experimental Javascript fetaures' in Chrome to mean 'enable staged features' (per our process https://developers.google.com/v8/launchprocess). This means that this flag really enables only those features that we consider quite mature, in particular they are expected to be stable and implementation of them must be complete. With that, we plan to evangelize enabling this flag among the power users, so that we hear about any breakage early. Can we set enable staged features for the Dev channel by default to increase usage? I don't actually think this will solve the problem since experience has shown us that not enough users run on that channel to catch all of the incompatibility issues, but at least it's a start. Dmitry On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org wrote: [FYI +blink-dev] ES6 extends String.prototype with several methods: repeat, startsWith, endsWith, includes, codePointAt) and adds String.fromCodePoint method. Firefox ships codePointAt and fromCodePoint since release 29 [1], startsWith and endsWith since release 17 [2], and repeat since release 24 [3]. 'include' was previously named 'contains' and has been renamed at the last TC39 meeting. Firefox shipped 'contains' since release 17. These methods has been available under a flag for a while, and were staged in Chrome 40. [1] https://developer.mozilla.org/en-US/Firefox/Releases/29 [2] https://developer.mozilla.org/en-US/Firefox/Releases/17 [3] https://developer.mozilla.org/en-US/Firefox/Releases/24 Owners: yang...@chromium.org, dslo...@chromium.org 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] Re: [blink-dev] Intent to ship: ES6 String functions
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). Just making this change with no stats around conflicts would be like the blink team deprecating an API without first measuring how often it's used. I disagree. This does not deprecate anything. Going forward, we have recently changed the definition of 'Experimental Javascript fetaures' in Chrome to mean 'enable staged features' (per our process https://developers.google.com/v8/launchprocess). This means that this flag really enables only those features that we consider quite mature, in particular they are expected to be stable and implementation of them must be complete. With that, we plan to evangelize enabling this flag among the power users, so that we hear about any breakage early. Can we set enable staged features for the Dev channel by default to increase usage? I don't actually think this will solve the problem since experience has shown us that not enough users run on that channel to catch all of the incompatibility issues, but at least it's a start. That would be great - I am sympathetic to that; but we typically have no feature distinction between Canary/Dev and subsequent Beta. Dmitry On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org wrote: [FYI +blink-dev] ES6 extends String.prototype with several methods: repeat, startsWith, endsWith, includes, codePointAt) and adds String.fromCodePoint method. Firefox ships codePointAt and fromCodePoint since release 29 [1], startsWith and endsWith since release 17 [2], and repeat since release 24 [3]. 'include' was previously named 'contains' and has been renamed at the last TC39 meeting. Firefox shipped 'contains' since release 17. These methods has been available under a flag for a while, and were staged in Chrome 40. [1] https://developer.mozilla.org/en-US/Firefox/Releases/29 [2] https://developer.mozilla.org/en-US/Firefox/Releases/17 [3] https://developer.mozilla.org/en-US/Firefox/Releases/24 Owners: yang...@chromium.org, dslo...@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] Re: [blink-dev] Intent to ship: ES6 String functions
On Thu Nov 27 2014 at 11:39:17 AM 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). You can collect stats via i::Isolate::CountUsage() Just making this change with no stats around conflicts would be like the blink team deprecating an API without first measuring how often it's used. I disagree. This does not deprecate anything. Going forward, we have recently changed the definition of 'Experimental Javascript fetaures' in Chrome to mean 'enable staged features' (per our process https://developers.google.com/v8/launchprocess). This means that this flag really enables only those features that we consider quite mature, in particular they are expected to be stable and implementation of them must be complete. With that, we plan to evangelize enabling this flag among the power users, so that we hear about any breakage early. Can we set enable staged features for the Dev channel by default to increase usage? I don't actually think this will solve the problem since experience has shown us that not enough users run on that channel to catch all of the incompatibility issues, but at least it's a start. That would be great - I am sympathetic to that; but we typically have no feature distinction between Canary/Dev and subsequent Beta. Dmitry On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org wrote: [FYI +blink-dev] ES6 extends String.prototype with several methods: repeat, startsWith, endsWith, includes, codePointAt) and adds String.fromCodePoint method. Firefox ships codePointAt and fromCodePoint since release 29 [1], startsWith and endsWith since release 17 [2], and repeat since release 24 [3]. 'include' was previously named 'contains' and has been renamed at the last TC39 meeting. Firefox shipped 'contains' since release 17. These methods has been available under a flag for a while, and were staged in Chrome 40. [1] https://developer.mozilla.org/en-US/Firefox/Releases/29 [2] https://developer.mozilla.org/en-US/Firefox/Releases/17 [3] https://developer.mozilla.org/en-US/Firefox/Releases/24 Owners: yang...@chromium.org, dslo...@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] Re: [blink-dev] Intent to ship: ES6 String functions
On Thu, Nov 27, 2014 at 11:44 AM, Jochen Eisinger joc...@chromium.org wrote: On Thu Nov 27 2014 at 11:39:17 AM 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). You can collect stats via i::Isolate::CountUsage() This is not a problem. A problem is detecting the problematic condition. Basically we need to count the incompatible additions of 'includes' to String.prototype, and things like 'includes' in a where a is something that is derived from String. What does incompatible mean here is unclear (e.g. es6 polyfill that adds 'includes' will be quite ok) Just making this change with no stats around conflicts would be like the blink team deprecating an API without first measuring how often it's used. I disagree. This does not deprecate anything. Going forward, we have recently changed the definition of 'Experimental Javascript fetaures' in Chrome to mean 'enable staged features' (per our process https://developers.google.com/v8/launchprocess). This means that this flag really enables only those features that we consider quite mature, in particular they are expected to be stable and implementation of them must be complete. With that, we plan to evangelize enabling this flag among the power users, so that we hear about any breakage early. Can we set enable staged features for the Dev channel by default to increase usage? I don't actually think this will solve the problem since experience has shown us that not enough users run on that channel to catch all of the incompatibility issues, but at least it's a start. That would be great - I am sympathetic to that; but we typically have no feature distinction between Canary/Dev and subsequent Beta. Dmitry On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org wrote: [FYI +blink-dev] ES6 extends String.prototype with several methods: repeat, startsWith, endsWith, includes, codePointAt) and adds String.fromCodePoint method. Firefox ships codePointAt and fromCodePoint since release 29 [1], startsWith and endsWith since release 17 [2], and repeat since release 24 [3]. 'include' was previously named 'contains' and has been renamed at the last TC39 meeting. Firefox shipped 'contains' since release 17. These methods has been available under a flag for a while, and were staged in Chrome 40. [1] https://developer.mozilla.org/en-US/Firefox/Releases/29 [2] https://developer.mozilla.org/en-US/Firefox/Releases/17 [3] https://developer.mozilla.org/en-US/Firefox/Releases/24 Owners: yang...@chromium.org, dslo...@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] Re: [blink-dev] Intent to ship: ES6 String functions
One suggestion that came out of discussions with folks is: - add an on-by-default flag 'Enable new Javascript features' that could be turned off at run-time. Javascript features we ship will be under that flag for 1 stable release. I'll investigate feasibility of that. On Thu, Nov 27, 2014 at 11:39 AM, 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). Just making this change with no stats around conflicts would be like the blink team deprecating an API without first measuring how often it's used. I disagree. This does not deprecate anything. Going forward, we have recently changed the definition of 'Experimental Javascript fetaures' in Chrome to mean 'enable staged features' (per our process https://developers.google.com/v8/launchprocess). This means that this flag really enables only those features that we consider quite mature, in particular they are expected to be stable and implementation of them must be complete. With that, we plan to evangelize enabling this flag among the power users, so that we hear about any breakage early. Can we set enable staged features for the Dev channel by default to increase usage? I don't actually think this will solve the problem since experience has shown us that not enough users run on that channel to catch all of the incompatibility issues, but at least it's a start. That would be great - I am sympathetic to that; but we typically have no feature distinction between Canary/Dev and subsequent Beta. Dmitry On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org wrote: [FYI +blink-dev] ES6 extends String.prototype with several methods: repeat, startsWith, endsWith, includes, codePointAt) and adds String.fromCodePoint method. Firefox ships codePointAt and fromCodePoint since release 29 [1], startsWith and endsWith since release 17 [2], and repeat since release 24 [3]. 'include' was previously named 'contains' and has been renamed at the last TC39 meeting. Firefox shipped 'contains' since release 17. These methods has been available under a flag for a while, and were staged in Chrome 40. [1] https://developer.mozilla.org/en-US/Firefox/Releases/29 [2] https://developer.mozilla.org/en-US/Firefox/Releases/17 [3] https://developer.mozilla.org/en-US/Firefox/Releases/24 Owners: yang...@chromium.org, dslo...@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.
Re: [v8-users] Re: [blink-dev] Intent to ship: ES6 String functions
On 27 November 2014 at 12:09, Dmitry Lomov dslo...@chromium.org wrote: One suggestion that came out of discussions with folks is: - add an on-by-default flag 'Enable new Javascript features' that could be turned off at run-time. Javascript features we ship will be under that flag for 1 stable release. I'll investigate feasibility of that. AFAICS, this would be equivalent to turning on --harmony/Experimental JavaScript by default, and hence redefining staging to mean ship with opt-out. That might make sense, but requires reconsidering our staging criteria. We'll have to discuss this some more. /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.
Re: [v8-users] Re: [blink-dev] Intent to ship: ES6 String functions
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.
[v8-users] Re: [blink-dev] Intent to ship: ES6 String functions
On Thu, Nov 27, 2014 at 12:52 PM, Philip Jägenstedt phil...@opera.com wrote: It sure sounds like 'contains' would be less likely to cause trouble, and is also a slightly better name IMHO. Is Mozilla on board with renaming it? If they're not keen, I think following their lead with 'contains' makes more sense. The renaming of `contains` to `includes` was decided at the recent TC39 meeting: https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-11/nov-18.md#51--44-arrayprototypecontains-and-stringprototypecontains `contains` was breaking the web (for both `String` and `Array`). -- -- 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] Re: [blink-dev] Intent to ship: ES6 String functions
This is very debateable, really. To me, it makes sense (and in my experience, also exists) that contains makes more sense (as a shortcuts for return this.indexOf(str) !== -1) than 'includes'. ☆*PhistucK* On Thu, Nov 27, 2014 at 1:52 PM, Philip Jägenstedt phil...@opera.com wrote: On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org wrote: 'include' was previously named 'contains' and has been renamed at the last TC39 meeting. Firefox shipped 'contains' since release 17. It sure sounds like 'contains' would be less likely to cause trouble, and is also a slightly better name IMHO. Is Mozilla on board with renaming it? If they're not keen, I think following their lead with 'contains' makes more sense. Philip 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] Re: [blink-dev] Intent to ship: ES6 String functions
On Thu, Nov 27, 2014 at 12:54 PM, Mathias Bynens mathi...@opera.com wrote: On Thu, Nov 27, 2014 at 12:52 PM, Philip Jägenstedt phil...@opera.com wrote: It sure sounds like 'contains' would be less likely to cause trouble, and is also a slightly better name IMHO. Is Mozilla on board with renaming it? If they're not keen, I think following their lead with 'contains' makes more sense. The renaming of `contains` to `includes` was decided at the recent TC39 meeting: https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-11/nov-18.md#51--44-arrayprototypecontains-and-stringprototypecontains `contains` was breaking the web (for both `String` and `Array`). Yes, 'contains' was breaking (IE reports that as well). -- -- 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] Re: [blink-dev] Intent to ship: ES6 String functions
*shortcut My last message was probably confusing, so continuing it - By that, I mean that it makes more sense for 'contains' to exists already on the web, than for 'includes'. ☆*PhistucK* On Thu, Nov 27, 2014 at 1:55 PM, PhistucK phist...@gmail.com wrote: This is very debateable, really. To me, it makes sense (and in my experience, also exists) that contains makes more sense (as a shortcuts for return this.indexOf(str) !== -1) than 'includes'. ☆*PhistucK* On Thu, Nov 27, 2014 at 1:52 PM, Philip Jägenstedt phil...@opera.com wrote: On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org wrote: 'include' was previously named 'contains' and has been renamed at the last TC39 meeting. Firefox shipped 'contains' since release 17. It sure sounds like 'contains' would be less likely to cause trouble, and is also a slightly better name IMHO. Is Mozilla on board with renaming it? If they're not keen, I think following their lead with 'contains' makes more sense. Philip 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] Re: [blink-dev] Intent to ship: ES6 String functions
*exist 'contains' is the obvious choice, 'includes' is not. This is what I mean. While 'contains' is better named, 'includes' is less risky and therefore should be chosen. I am finally done, I think. Sorry for the triple post. ☆*PhistucK* On Thu, Nov 27, 2014 at 1:57 PM, PhistucK phist...@gmail.com wrote: *shortcut My last message was probably confusing, so continuing it - By that, I mean that it makes more sense for 'contains' to exists already on the web, than for 'includes'. ☆*PhistucK* On Thu, Nov 27, 2014 at 1:55 PM, PhistucK phist...@gmail.com wrote: This is very debateable, really. To me, it makes sense (and in my experience, also exists) that contains makes more sense (as a shortcuts for return this.indexOf(str) !== -1) than 'includes'. ☆*PhistucK* On Thu, Nov 27, 2014 at 1:52 PM, Philip Jägenstedt phil...@opera.com wrote: On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org wrote: 'include' was previously named 'contains' and has been renamed at the last TC39 meeting. Firefox shipped 'contains' since release 17. It sure sounds like 'contains' would be less likely to cause trouble, and is also a slightly better name IMHO. Is Mozilla on board with renaming it? If they're not keen, I think following their lead with 'contains' makes more sense. Philip 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.
Re: [v8-users] Re: [blink-dev] Intent to ship: ES6 String functions
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.
Re: [v8-users] Re: [blink-dev] Intent to ship: ES6 String functions
Firefox simply got lucky in the case of the referenced bug, because some web pages serve different code depending on what browser they encounter. On 27 November 2014 at 13:14, Mathias Bynens mathi...@opera.com wrote: On Thu, Nov 27, 2014 at 1:06 PM, Philip Jägenstedt phil...@opera.com wrote: On Thu, Nov 27, 2014 at 12:54 PM, Mathias Bynens mathi...@opera.com wrote: On Thu, Nov 27, 2014 at 12:52 PM, Philip Jägenstedt phil...@opera.com wrote: It sure sounds like 'contains' would be less likely to cause trouble, and is also a slightly better name IMHO. Is Mozilla on board with renaming it? If they're not keen, I think following their lead with 'contains' makes more sense. The renaming of `contains` to `includes` was decided at the recent TC39 meeting: https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-11/nov-18.md#51--44-arrayprototypecontains-and-stringprototypecontains `contains` was breaking the web (for both `String` and `Array`). That's really unfortunate, it's going to be silly to have e.g. DOMStringList.contains but Array.includes... Yep. But it is what it is. :( What kind of content is breaking, and how has Firefox been able to ship with .contains since November 2012? https://code.google.com/p/chromium/issues/detail?id=409858 is an example. -- -- 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.
Re: [v8-users] Re: [blink-dev] Intent to ship: ES6 String functions
Then I guess I am also looking to help educate about new platform features. I understand this use case is much less needed, though. ☆*PhistucK* On Thu, Nov 27, 2014 at 9:52 PM, Dmitry Lomov dslo...@chromium.org wrote: On Thu, Nov 27, 2014 at 8:48 PM, PhistucK phist...@gmail.com wrote: Well, you got the wrong idea. I am looking to help developers, not to tell them something is necessarily wrong. The expensive ones (like includes in obj) are not part of best available in my opinion. These are the ones that cause problems though (both in 'values' case and in Array.prototype.contains case). foo = obj.includes, obj.includes() and String.prototype.includes = foo are enough. These typically wouldn't cause problems (as in: won't break web sites) since all this likely overrides the ones we ship. The point is to note that this new, potentially controversial (its name only, of course) feature was introduced and that if you suddenly see issues, take a note that it was added, in case it applies to your case. If not, carry on. Logs such as these - String.prototype.includes was recently added to the platform and was overridden by this website. If you expect the standard variation of this method, perhaps polyfill it only when it does not exist. String.prototype.includes was recently added to the platform and used by this website. If you see issues, consider this as a possible culprit. ☆*PhistucK* On Thu, Nov 27, 2014 at 2:01 PM, Dmitry Lomov dslo...@chromium.org wrote: 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
