987762 - Firefox 28.0 javascript xhr raw response object (from json API) has a property 'entries' which is a [native code] function

Status: RESOLVED INVALID

Description

[scotland.stephenson]

Attachment: ff_28_response_bug.png screen cap of bug in firebug console

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36

Steps to reproduce:

1) Using a Backbone Collection.  Request a json response via Collection.fetch().  
2) In the parse method (which receives the raw response) - we have a conditional to return either response.entries if it exists, or the response itself if not.

- in Firefox < 28.0 works as expected
- in Firefox 28.0 the response.entries is a native code function


Actual results:

collection parse returns a native code javascript function as a value.


Expected results:

collection parse is assigned an array of javascript models

Comment 1

[Boris Zbarsky [:bzbarsky, bz on IRC]]

EcmaScript 6 adds an "entries" method to arrays.  See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.entries

It looks like we added this in bug 894658, which was fixed for Firefox 28.

The right solution is probably to change your conditional to check for an own "entries" property, as opposed to an "entries" property anywhere on the prototype chain.

Comment 2

[Boris Zbarsky [:bzbarsky, bz on IRC]]

By the way, is this parse method that checks for "entries" something custom to your setup, or part of some library you're using (or authoring)?

Comment 3

[scotland.stephenson]

Yes.  It is part of a custom paginated-data response on a GET request for a collection.  
Since these methods are to be a standard part of ECMA6 we'll just have to adjust.  It will be interesting to see how many things get tripped up by the keys, values, entries methods in a similar manner.

Thanks for looking into it

Comment 4

[Boris Zbarsky [:bzbarsky, bz on IRC]]

> It will be interesting to see how many things get tripped up

Indeed.  The "values" case caused enough problems we had to back it out for the time being while the committee figures out how to make it cause fewer problems.  :(  See bug 875433 and the bugs it depends on and the thread starting https://mail.mozilla.org/pipermail/es-discuss/2013-June/031390.html if you're interested in the gory details.

Comment 5

[Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat)]

Added to https://developer.mozilla.org/en-US/Firefox/Releases/28/Site_Compatibility

Is this still an issue? Or fixed by Oracle?

Comment 6

[Thomas Wisniewski]

Since this turned out to not be a bug with Firefox, but rather something from ES6 that sites have to adjust to, I'm closing this as INVALID.

Comment 7

[Mike Taylor [:miketaylr]]

Typically we don't close these as INVALID, we move them to Tech Evangelism and attempt outreach.

Before re-opening though, does this issue still exist?

Comment 8

[Thomas Wisniewski]

Ah, ok. The basic conflict must still exist, as per ES6 all arrays have an "entries" object.

However, in comment 3 the reporter did mention that they understood this and would adjust their code appropriately (in 2014), so I would be surprised if it was still an issue given the lack of subsequent comments.

I also can't see this as being a major evangelism issue at this point, as Firefox isn't the only browser it would happen in, and quick searches in Bugzilla and on the WebCompat site don't show anything obvious.