I was tinkering around with JavaScript proxies, first trying it with a pure JavaScript object. Then I tried it with a nsIDOMDocument on FF4 beta 8, Fedora 14, and my CPU started spinning endlessly. I tried to reproduce it on Windows 7 x64 with FF4 trunk, and crashed.

Without the onload call, I crash on Windows x64, but MSVC 2008 Express is not able to trap the assertion failure, and FF4 simply crashes on the same line: Assertion failure: wrapper->isWrapper(), at c:/trunk/base/mozilla/js/src/xpconnect/wrappers/AccessCheck.cpp:370

gal, mrbkap: can one of you please explain what the assertion failure means? JS_ASSERT(wrapper->isWrapper()); I'm just looking for a little insight, to see if there's anything I can do or learn from this.

jst: I nominated this for blocking FF4 7 days ago. What do you think: hardblocker, softblocker, notablocker?

Its at least a crash so we should look at it. Probably an easy fix.

This WFM with TM debug. I think bug 626290 fixed this.

(In reply to comment #5) > This WFM with TM debug. I think bug 626290 fixed this. I'd appreciate a cc on that bug, please. When you said "WFM", did you mean it wasn't crashing, or that it was generating useful results? (I realize the data variable's contents didn't end up in the "output" textarea afterwards... I guess I over-minimized the testcase in that respect.)

I shouldn't have linked a hidden bug from an open bug with a test case. I will hide this one. Alex, I added you to the other one as well. I only checked that we no longer crash.

Actually we need another spot fix for this after all. Alex, I will land this patch shortly. After that please try your test case with the tracemonkey nightly if you can.

cdleary-bot mozilla-central merge info: http://hg.mozilla.org/mozilla-central/rev/b03242ce2fce Note: not marking as fixed because fixed-in-tracemonkey is not present on the whiteboard.

Further testing shows this isn't enough. Sure, we fixed the crash, and it's not hanging... but it throws NS_ERROR_XPC_BAD_CONVERT_JS calling doc.getElementById("test"). I'm not sure this should still be a hardblocker based on that (it's a bug in a very new feature)... but I can't say this is fixed to my satisfaction. (I am aware that in this testcase, several values will come up false, because proxies don't support equality comparisons directly. That's fine - I have other JS proxy code I've written to take care of that.)

Alex, can you file a new bug with the new test case? We will fix it there. Please cc me.

Filed as bug 627634.

OK, 627634 was invalid. However, I discovered further proxy oddities in bug 627648.