Enumerating new proxy-based DOM bindings should enumerate the prototype too

VERIFIED FIXED in Firefox 12



6 years ago
5 years ago


(Reporter: peterv, Assigned: peterv)



Dependency tree / graph

Firefox Tracking Flags

(firefox11+ wontfix, firefox12+ verified, firefox13+ verified)


(Whiteboard: [qa!])


(1 attachment)

Comment hidden (empty)


6 years ago
Duplicate of this bug: 724033
This is apparently affecting sites in the wild.
tracking-firefox11: --- → ?
tracking-firefox12: --- → ?
tracking-firefox13: --- → ?
Whiteboard: regression

Comment 3

6 years ago
Tracking, but it'd be good to get more context of the sites that are affected by this bug. bug 648801 and bug 724033 didn't appear to have any pointers.
tracking-firefox11: ? → +
tracking-firefox12: ? → +
tracking-firefox13: ? → +

Comment 4

6 years ago
In our case, it was in an extension, and we got bitten by this in two different ways.

First, we were trying to expose DOM elements from one origin to a sandbox with a different origin, using old code that iterated over an object with for(var i in obj) and created getters for the properties (from the days before JS proxy support). That got broken, but we should have switched to using proxies anyway and now we have.

Second, we created new code that used for(var i in nodeList) to iterate over the nodes in a NodeList. This is the wrong way to do it, but it worked in Firefox 10. We then realized that this code broke under Firefox 9.

The first case probably isn't a particularly big deal, since I doubt many other developers are affected. The second case is perhaps a bigger deal, since developers could end up writing code that won't work in later Firefox versions or in other browsers without noticing it.

Comment 5

6 years ago
Created attachment 595127 [details] [diff] [review]
Assignee: nobody → peterv
Attachment #595127 - Flags: review?(mrbkap)


6 years ago
Attachment #595127 - Flags: review?(mrbkap) → review+
[Triage Comment]
Once landed on mozilla-central, if the patch is considered low-risk, please consider nominating for mozilla-aurora and mozilla-beta

Comment 7

6 years ago
I've sent email to Peter about whether we should consider landing on m-c uplifting to FF11.
Backed out due to browser-chrome tests failures.
off-hand I'm not sure if it's fault of this patch or if the tests are relying on some wrong behavior that this patch fixes

it's practically all newtab tests with failures similar to:

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/newtab/browser_newtab_block.js | an unexpected uncaught JS exception reported through window.onerror - this._node.addEventListener is not a function at chrome://browser/content/newtab/newTab.js:715

cc-int Tim who worked on newtab page.

Comment 9

6 years ago
The problem seems to be |let cells = [new Cell(this, child) for each (child in children)];| in newTab.js, with children a NodeList.

Comment 10

6 years ago
If I'm not mistaken that will create Cell objects for properties on the NodeList prototype, which doesn't seem what this code wants to do.
Depends on: 730484
(In reply to Peter Van der Beken [:peterv] from comment #9)
> The problem seems to be |let cells = [new Cell(this, child) for each (child
> in children)];| in newTab.js, with children a NodeList.

Yeah, silly mistake :/ Filed bug 730484 and attached a patch.
Peter, there is a reviewed patch ready for checkin attached to bug 730484. Do you want to land it together with the patch from this bug? I usually land patches on fx-team, so I have no inbound repo and figured you might not want to wait until that gets merged.

Comment 13

6 years ago
Target Milestone: --- → mozilla13
Last Resolved: 6 years ago
Resolution: --- → FIXED
Comment on attachment 595127 [details] [diff] [review]

[Approval Request Comment]
Regression caused by (bug #): 648801
User impact if declined: websites broken...
Testing completed (on m-c, etc.): landed a couple of days ago
Risk to taking this patch (and alternatives if risky): low risk
String changes made by this patch: none

I think this is something we could, and should, take on aurora. We have a duplicate already filed, and it's a very safe patch, low risk.
Attachment #595127 - Flags: approval-mozilla-aurora?
Comment on attachment 595127 [details] [diff] [review]

[Triage Comment]
Approving for Aurora 12. Discussed the possibility of nominating for mozilla-beta with jst, but we feel it carries too much risk for our fifth beta.
Attachment #595127 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 17

6 years ago
status-firefox12: --- → fixed
Backed out on Aurora:

because of test failures:

It looks like bug 730484 fixes these test failures.  If appropriate, please request approval to land bug 730484 on Aurora, so the two patches can land together.
status-firefox12: fixed → affected


6 years ago
status-firefox11: --- → wontfix

Comment 19

6 years ago
status-firefox12: affected → fixed
Is this something QA can verify?
Keywords: regression
Whiteboard: regression → [qa?]
Yes.  There's a test in the patch you can verify with.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #21)
> Yes.  There's a test in the patch you can verify with.

Can you give a little instruction about how to use the test in the patch?
Whiteboard: [qa?] → [qa+]


5 years ago
status-firefox13: --- → fixed

Comment 23

5 years ago
Verified that the test from the patch is passing on all the OSs:
status-firefox12: fixed → verified

Comment 24

5 years ago
The test from the patch(test_bug691707.html) is also passing on Firefox 13 beta 1:
status-firefox13: fixed → verified
Whiteboard: [qa+] → [qa!]
You need to log in before you can comment on or make changes to this bug.