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

RESOLVED INVALID

Status

()

defect
RESOLVED INVALID
5 years ago
3 years ago

People

(Reporter: scotland.stephenson, Unassigned)

Tracking

({site-compat})

28 Branch
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

5 years ago
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
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
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.
Blocks: 894658
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)?
Flags: needinfo?(scotland.stephenson)
Reporter

Comment 3

5 years ago
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
> 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.
Flags: needinfo?(scotland.stephenson)

Comment 6

3 years ago
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.
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
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?
Flags: needinfo?(scotland.stephenson)

Comment 8

3 years ago
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.
Flags: needinfo?(scotland.stephenson)
You need to log in before you can comment on or make changes to this bug.