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.

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.

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 on attachment 595127[details][diff][review]
v1
[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.

Comment on attachment 595127[details][diff][review]
v1
[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.