BUILD: Current trunk firefox STEPS TO REPRODUCE: 1) Start firefox 2) Hit Ctrl-u to open view-source ACTUAL RESULTS: ###!!! ASSERTION: null script filename: 'flags != JSFILENAME_NULL', file ../../../../../mozilla/js/src/xpconnect/src/xpcconvert.cpp, line 1081 EXPECTED RESULTS: no assert.

BL is bad. It was passing a null filename. I went with using the URI of the ownerDocument of the node we got our event handler script from in that case. Note that for non-key handlers mPrototypeBinding must not be null, so the null-check there is redundant.

Comment on attachment 184341 [details] [diff] [review] Patch r+sr=jst

This is an improvement for sure. But shouldn't we use a real XBL file, and a non-zero line number? /be

Comment on attachment 184341 [details] [diff] [review] Patch requesting 1.8b2 approval for not passing null as the script filename into the JS engine, which causes asserts and could even give some user XBL expanded permissions in some cases.

Brendan, there is no "real XBL" involved. A <xul:key> element is implemented by creating an XBLPrototypeHandler in a vacuum (without any binding) and then calling ExecuteHandler() on it when the <key> is triggered. See content/xbl/src/nsXBLWindowKeyHandler.cpp and the second XBLPrototypeHandler constructor at http://lxr.mozilla.org/seamonkey/source/content/xbl/src/nsXBLPrototypeHandler.cpp#133 (note that it sets mPrototypeBinding to null). The "right" line number would be that of the <key> or <command> node (whichever we used) in the XUL file. There's no way for us to find that out from here.

Comment on attachment 184341 [details] [diff] [review] Patch a=asa