Closed
Bug 390488
Opened 16 years ago
Closed 16 years ago
[FIXr]Event listeners should have access to the JS callstack
Categories
(Core :: DOM: Events, defect, P2)
Core
DOM: Events
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha8
People
(Reporter: moz.jomel, Assigned: bzbarsky)
References
()
Details
(4 keywords)
Attachments
(2 files)
1.54 KB,
application/x-xpinstall
|
Details | |
6.64 KB,
patch
|
jst
:
review+
brendan
:
superreview+
dveditz
:
approval1.8.1.8+
dveditz
:
approval1.8.0.13+
jst
:
approval1.9+
|
Details | Diff | Splinter Review |
As of Firefox 2.0.0.5 rc1 [1], chrome event listeners can no longer obtain the stacktrace that led to the event, whether they use (new Error).stack or arguments.callee.caller[.caller...]. These were useful for dump debugging and even in extension code to adjust behaviour based on the source of events. The change was since Firefox 2.0.0.4 rc3 [2], possibly due to bug 326777 [3]. According to Boris Zbarsky on IRC, this effect was unintended however, and event listeners should continue to be able to obtain stack traces. I've attached a tiny testcase extension, just install then click Tools->Test Event Stacktraces (an extension was the easiest way to test with chrome privileges). [1]: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2.0.0.5-candidates/rc1/unsigned/firefox-2.0.0.5.en-US.win32.zip [2]: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2.0.0.4-candidates/rc3/unsigned/firefox-2.0.0.4.en-US.win32.zip [3]: Relevant checkins are: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=bzbarsky%25mit.edu&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-10+14%3A17&maxdate=2007-07-10+14%3A24&cvsroot=%2Fcvsroot
![]() |
Assignee | |
Comment 1•16 years ago
|
||
So this is a regression from bug 371858 of sorts: when event handling pushes its JSContext on the stack, we save off its stackframe, even though this JSContext is already what's at the top of the stack. It's easy enough to detect this case and not save off the stack, and I think for branch we should do exactly that...
Blocks: 371858
Summary: Event listeners should → Event listeners should have access to the JS callstack
Reporter | ||
Comment 2•16 years ago
|
||
I've added a simpler content only testcase to the URL field. This simulates a click, and checks that it can detect that it did so.
![]() |
Assignee | |
Comment 3•16 years ago
|
||
The idea here is to not clear out the JS frame stack if the context being pushed is what's already at that top. We'd still clear it when pushing a null context, of course.
Attachment #274833 -
Flags: superreview?(brendan)
Attachment #274833 -
Flags: review?(jst)
Attachment #274833 -
Flags: approval1.8.1.7?
Attachment #274833 -
Flags: approval1.8.0.13?
![]() |
Assignee | |
Updated•16 years ago
|
Priority: -- → P2
Summary: Event listeners should have access to the JS callstack → [FIX]Event listeners should have access to the JS callstack
Target Milestone: --- → mozilla1.9 M8
Updated•16 years ago
|
Attachment #274833 -
Flags: review?(jst) → review+
Updated•16 years ago
|
Attachment #274833 -
Flags: superreview?(brendan) → superreview+
![]() |
Assignee | |
Updated•16 years ago
|
Summary: [FIX]Event listeners should have access to the JS callstack → [FIXr]Event listeners should have access to the JS callstack
![]() |
Assignee | |
Comment 4•16 years ago
|
||
Comment on attachment 274833 [details] [diff] [review] Proposed fix Fix for a regression from one of our security fixes. Risk of a security regression is small, and there is basically no risk of functionality regressions.
Attachment #274833 -
Flags: approval1.9?
Updated•16 years ago
|
Attachment #274833 -
Flags: approval1.9? → approval1.9+
![]() |
Assignee | |
Comment 5•16 years ago
|
||
Checked in, with the tests.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Updated•16 years ago
|
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.7?
Comment 6•16 years ago
|
||
Comment on attachment 274833 [details] [diff] [review] Proposed fix approved for 1.8.0.13 and 1.8.1.7, a=dveditz
Attachment #274833 -
Flags: approval1.8.1.7?
Attachment #274833 -
Flags: approval1.8.1.7+
Attachment #274833 -
Flags: approval1.8.0.13?
Attachment #274833 -
Flags: approval1.8.0.13+
Updated•16 years ago
|
Flags: blocking1.8.1.8?
You need to log in
before you can comment on or make changes to this bug.
Description
•