Closed
Bug 295160
Opened 19 years ago
Closed 19 years ago
Null filename assert at js/src/xpconnect/src/xpcconvert.cpp, line 1081
Categories
(Core :: XBL, defect)
Core
XBL
Tracking
()
RESOLVED
FIXED
mozilla1.8beta2
People
(Reporter: bzbarsky, Assigned: bzbarsky)
References
Details
Attachments
(1 file)
2.83 KB,
patch
|
jst
:
review+
jst
:
superreview+
asa
:
approval1.8b2+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•19 years ago
|
||
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.
Attachment #184341 -
Flags: superreview?(jst)
Attachment #184341 -
Flags: review?(jst)
Comment 2•19 years ago
|
||
Comment on attachment 184341 [details] [diff] [review] Patch r+sr=jst
Attachment #184341 -
Flags: superreview?(jst)
Attachment #184341 -
Flags: superreview+
Attachment #184341 -
Flags: review?(jst)
Attachment #184341 -
Flags: review+
Comment 3•19 years ago
|
||
This is an improvement for sure. But shouldn't we use a real XBL file, and a non-zero line number? /be
Assignee: general → general
Component: JavaScript Engine → XBL
Flags: blocking1.8b2+
OS: Linux → All
Hardware: PC → All
Assignee | ||
Comment 4•19 years ago
|
||
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.
Attachment #184341 -
Flags: approval1.8b2?
Assignee | ||
Comment 5•19 years ago
|
||
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 6•19 years ago
|
||
Comment on attachment 184341 [details] [diff] [review] Patch a=asa
Attachment #184341 -
Flags: approval1.8b2? → approval1.8b2+
Assignee | ||
Updated•19 years ago
|
Assignee: general → bzbarsky
Assignee | ||
Updated•19 years ago
|
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8beta2
You need to log in
before you can comment on or make changes to this bug.
Description
•