.entries() vs. the web

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

.entries() vs. the web

Oliver Hunt-2
It turns out there are a number of sites (such as mobile.twitter.com) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided.

We're removing it from JSC now, until we can find a way to expose it without causing site breakage, although this does seem like fixing it would require bringing back the awful "pretend that you're undefined" horror.

--Oliver


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: .entries() vs. the web

Tab Atkins Jr.
On Mon, Jun 16, 2014 at 4:08 PM, Oliver Hunt <[hidden email]> wrote:
> It turns out there are a number of sites (such as mobile.twitter.com) that
> are property detecting .entries on objects, and that means that they're
> breaking when Array.prototype.entries is provided.

What are they using the detection for?

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: .entries() vs. the web

Erik Arvidsson
In reply to this post by Oliver Hunt-2

That is why you need to implement @unscopables too.

On Jun 16, 2014 7:08 PM, "Oliver Hunt" <[hidden email]> wrote:
It turns out there are a number of sites (such as mobile.twitter.com) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided.

We're removing it from JSC now, until we can find a way to expose it without causing site breakage, although this does seem like fixing it would require bringing back the awful "pretend that you're undefined" horror.

--Oliver


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: .entries() vs. the web

Oliver Hunt-2
@@unscopeable doesn't work as they are not using |with|

The logic is something along the lines of 

if (foo.entries) ...

It looks like there are paths that objects or arrays may path through, with "entries" being a perfectly reasonable property name in the object case, but now the array case hits the entries property on Array.prototype

--Oliver

On Jun 16, 2014, at 4:10 PM, Erik Arvidsson <[hidden email]> wrote:

That is why you need to implement @unscopables too.

On Jun 16, 2014 7:08 PM, "Oliver Hunt" <[hidden email]> wrote:
It turns out there are a number of sites (such as mobile.twitter.com) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided.

We're removing it from JSC now, until we can find a way to expose it without causing site breakage, although this does seem like fixing it would require bringing back the awful "pretend that you're undefined" horror.

--Oliver


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: .entries() vs. the web

Claude Pache
In reply to this post by Oliver Hunt-2
Apparently, this problem was already known more than 4 months ago:

        https://bugzilla.mozilla.org/show_bug.cgi?id=924386#c19

I guess it specifically affect the mobile web? for it didn't prevent Firefox to ship `Array.prototype.entries` in v28, released on March 18.

—Claude

Le 17 juin 2014 à 01:08, Oliver Hunt <[hidden email]> a écrit :

> It turns out there are a number of sites (such as mobile.twitter.com) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided.
>
> We're removing it from JSC now, until we can find a way to expose it without causing site breakage, although this does seem like fixing it would require bringing back the awful "pretend that you're undefined" horror.
>
> --Oliver
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: .entries() vs. the web

Andrea Giammarchi-2
This is a gently reminder I don't represent my company anyhow in this mailing list but actually I've been working on mobile web here at twitter for 1.5 years how ... thanks for the report, I'll do what I can (already patched, waiting reviews) + I don't think mobile web should block anyhow new standards no matter where I work.

Best Regards


On Mon, Jun 16, 2014 at 4:52 PM, Claude Pache <[hidden email]> wrote:
Apparently, this problem was already known more than 4 months ago:

        https://bugzilla.mozilla.org/show_bug.cgi?id=924386#c19

I guess it specifically affect the mobile web? for it didn't prevent Firefox to ship `Array.prototype.entries` in v28, released on March 18.

—Claude

Le 17 juin 2014 à 01:08, Oliver Hunt <[hidden email]> a écrit :

> It turns out there are a number of sites (such as mobile.twitter.com) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided.
>
> We're removing it from JSC now, until we can find a way to expose it without causing site breakage, although this does seem like fixing it would require bringing back the awful "pretend that you're undefined" horror.
>
> --Oliver
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: .entries() vs. the web

Brendan Eich-2
In reply to this post by Oliver Hunt-2
Would .items fare better, I wonder.

/be

Oliver Hunt wrote:

> It turns out there are a number of sites (such as mobile.twitter.com
> <http://mobile.twitter.com>) that are property detecting .entries on
> objects, and that means that they're breaking when
> Array.prototype.entries is provided.
>
> We're removing it from JSC now, until we can find a way to expose it
> without causing site breakage, although this does seem like fixing it
> would require bringing back the awful "pretend that you're undefined"
> horror.
>
> --Oliver
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: .entries() vs. the web

Rick Waldron



On Mon, Jun 16, 2014 at 11:11 PM, Brendan Eich <[hidden email]> wrote:
Would .items fare better, I wonder.

Or outreach to sites the break?

Rick
 

/be

Oliver Hunt wrote:
It turns out there are a number of sites (such as mobile.twitter.com <http://mobile.twitter.com>) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided.


We're removing it from JSC now, until we can find a way to expose it without causing site breakage, although this does seem like fixing it would require bringing back the awful "pretend that you're undefined" horror.

--Oliver

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: .entries() vs. the web

Alex Russell-4
Right. Would love to know the size/traffic of the "number of sites" affected.


On Tue, Jun 17, 2014 at 10:45 AM, Rick Waldron <[hidden email]> wrote:



On Mon, Jun 16, 2014 at 11:11 PM, Brendan Eich <[hidden email]> wrote:
Would .items fare better, I wonder.

Or outreach to sites the break?

Rick
 

/be

Oliver Hunt wrote:
It turns out there are a number of sites (such as mobile.twitter.com <http://mobile.twitter.com>) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided.


We're removing it from JSC now, until we can find a way to expose it without causing site breakage, although this does seem like fixing it would require bringing back the awful "pretend that you're undefined" horror.

--Oliver

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: .entries() vs. the web

Andrea Giammarchi-2
FWIW I think this is a non issue and "how many" should not be relevant.

If developers understand the issue, the fix is straight forward.

instead of doing this

```javascript
if (obj.entries) {
  // do stuff with entries
} else if(Array.isArray(obj)) {
  // do stuff with obj
}
```

or this

`var entries = obj.entries || obj;`

we should just advocate this:

```javascript
if (Array.isArray(obj)) {
  // do stuff with obj
} else if(obj.entries) {
  // do stuff with entry property
}
```

or using `instanceof` when the realm is not a problem (if performance is a concern and Array.isArray is the bottleneck which is rarely the case)

This also seems to be an API only related problem where both `Array` and `Object` could be passed as parameter but yeah, objects with properties named as `list`, `items`, or `entries` are quite common but I personally prefer a future proof approach/small refactoring than a stopper for new specs.

my 2 cents



On Tue, Jun 17, 2014 at 11:18 AM, Alex Russell <[hidden email]> wrote:
Right. Would love to know the size/traffic of the "number of sites" affected.


On Tue, Jun 17, 2014 at 10:45 AM, Rick Waldron <[hidden email]> wrote:



On Mon, Jun 16, 2014 at 11:11 PM, Brendan Eich <[hidden email]> wrote:
Would .items fare better, I wonder.

Or outreach to sites the break?

Rick
 

/be

Oliver Hunt wrote:
It turns out there are a number of sites (such as mobile.twitter.com <http://mobile.twitter.com>) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided.


We're removing it from JSC now, until we can find a way to expose it without causing site breakage, although this does seem like fixing it would require bringing back the awful "pretend that you're undefined" horror.

--Oliver

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: .entries() vs. the web

Alex Russell-4
On Tue, Jun 17, 2014 at 11:46 AM, Andrea Giammarchi <[hidden email]> wrote:
FWIW I think this is a non issue and "how many" should not be relevant.

If developers understand the issue, the fix is straight forward.

I wish to live in your world of unicorns and magic for in that world I AM A WIZARD.
 
instead of doing this

```javascript
if (obj.entries) {
  // do stuff with entries
} else if(Array.isArray(obj)) {
  // do stuff with obj
}
```

or this

`var entries = obj.entries || obj;`

we should just advocate this:

```javascript
if (Array.isArray(obj)) {
  // do stuff with obj
} else if(obj.entries) {
  // do stuff with entry property
}
```

or using `instanceof` when the realm is not a problem (if performance is a concern and Array.isArray is the bottleneck which is rarely the case)

This also seems to be an API only related problem where both `Array` and `Object` could be passed as parameter but yeah, objects with properties named as `list`, `items`, or `entries` are quite common but I personally prefer a future proof approach/small refactoring than a stopper for new specs.

my 2 cents



On Tue, Jun 17, 2014 at 11:18 AM, Alex Russell <[hidden email]> wrote:
Right. Would love to know the size/traffic of the "number of sites" affected.


On Tue, Jun 17, 2014 at 10:45 AM, Rick Waldron <[hidden email]> wrote:



On Mon, Jun 16, 2014 at 11:11 PM, Brendan Eich <[hidden email]> wrote:
Would .items fare better, I wonder.

Or outreach to sites the break?

Rick
 

/be

Oliver Hunt wrote:
It turns out there are a number of sites (such as mobile.twitter.com <http://mobile.twitter.com>) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided.


We're removing it from JSC now, until we can find a way to expose it without causing site breakage, although this does seem like fixing it would require bringing back the awful "pretend that you're undefined" horror.

--Oliver

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: .entries() vs. the web

Andrea Giammarchi-2


On Tue, Jun 17, 2014 at 11:47 AM, Alex Russell <[hidden email]> wrote:
On Tue, Jun 17, 2014 at 11:46 AM, Andrea Giammarchi <[hidden email]> wrote:
FWIW I think this is a non issue and "how many" should not be relevant.

If developers understand the issue, the fix is straight forward.

I wish to live in your world of unicorns and magic for in that world I AM A WIZARD.
 
instead of doing this

```javascript
if (obj.entries) {
  // do stuff with entries
} else if(Array.isArray(obj)) {
  // do stuff with obj
}
```

or this

`var entries = obj.entries || obj;`

we should just advocate this:

```javascript
if (Array.isArray(obj)) {
  // do stuff with obj
} else if(obj.entries) {
  // do stuff with entry property
}
```

or using `instanceof` when the realm is not a problem (if performance is a concern and Array.isArray is the bottleneck which is rarely the case)

This also seems to be an API only related problem where both `Array` and `Object` could be passed as parameter but yeah, objects with properties named as `list`, `items`, or `entries` are quite common but I personally prefer a future proof approach/small refactoring than a stopper for new specs.

my 2 cents



On Tue, Jun 17, 2014 at 11:18 AM, Alex Russell <[hidden email]> wrote:
Right. Would love to know the size/traffic of the "number of sites" affected.


On Tue, Jun 17, 2014 at 10:45 AM, Rick Waldron <[hidden email]> wrote:



On Mon, Jun 16, 2014 at 11:11 PM, Brendan Eich <[hidden email]> wrote:
Would .items fare better, I wonder.

Or outreach to sites the break?

Rick
 

/be

Oliver Hunt wrote:
It turns out there are a number of sites (such as mobile.twitter.com <http://mobile.twitter.com>) that are property detecting .entries on objects, and that means that they're breaking when Array.prototype.entries is provided.


We're removing it from JSC now, until we can find a way to expose it without causing site breakage, although this does seem like fixing it would require bringing back the awful "pretend that you're undefined" horror.

--Oliver

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss