Closed
Bug 987762
Opened 11 years ago
Closed 9 years ago
Firefox 28.0 javascript xhr raw response object (from json API) has a property 'entries' which is a [native code] function
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: scotland.stephenson, Unassigned)
References
Details
(Keywords: site-compat)
Attachments
(1 file)
1.62 MB,
image/png
|
Details |
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
Updated•11 years ago
|
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
![]() |
||
Comment 1•11 years ago
|
||
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
![]() |
||
Comment 2•11 years ago
|
||
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•11 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
![]() |
||
Comment 4•11 years ago
|
||
> 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.
![]() |
||
Updated•11 years ago
|
Flags: needinfo?(scotland.stephenson)
Updated•11 years ago
|
Keywords: site-compat
Comment 5•11 years ago
|
||
Added to https://developer.mozilla.org/en-US/Firefox/Releases/28/Site_Compatibility
Is this still an issue? Or fixed by Oracle?
Comment 6•9 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: 9 years ago
Resolution: --- → INVALID
Comment 7•9 years ago
|
||
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•9 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.
Description
•