Closed
Bug 342235
Opened 19 years ago
Closed 19 years ago
[FIX]XBL method trying to use event parameter gets exception
Categories
(Core :: DOM: Core & HTML, defect, P1)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha1
People
(Reporter: aaronr, Assigned: bzbarsky)
References
Details
(Keywords: regression)
Attachments
(3 files)
1.94 KB,
application/xhtml+xml
|
Details | |
1.02 KB,
application/xhtml+xml
|
Details | |
1.41 KB,
patch
|
markh
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
The attached testcase doesn't work on trunk but works in Firefox 1.5.0.5 nightly. I get the following in the java script console: "Error: uncaught exception: Permission denied to get property MouseEvent.originalTarget". If I had to guess, I'd say that it just broke within the last week.
The immediate impact is that this bug is killing some of the controls in the XForms extension.
I've looked at this a little and if you try to get the event.originalTarget using a method that is set directly as the onclick handler on the DOM element, it works fine. It also works fine if it is used in a click handler using xbl:handler. The issue seems to be with an anonymous content element passing the event to a xbl:method.
Comment 2•19 years ago
|
||
I can first time see this bug in 2006-06-13 nightlies.
Perhaps Bug 255942 or Bug 176182
Updated•19 years ago
|
Flags: blocking1.9a1?
Keywords: regression
Comment 3•19 years ago
|
||
So for some reason anonymous content can't access any properties of the event.
Updated•19 years ago
|
Blocks: dom-agnostic
![]() |
Assignee | |
Comment 4•19 years ago
|
||
So when we get into nsScriptSecurityManager::CheckSameOriginDOMProp (called from nsScriptSecurityManager::CheckPropertyAccessImpl), the subject principal is the principal of the page, as expected, but the object principal is the hidden window's principal. So it looks like we're wrapping the event in the wrong scope or something....
Flags: blocking1.9a1? → blocking1.9a1+
![]() |
Assignee | |
Comment 5•19 years ago
|
||
So what _used_ to happen is that in nsJSEventListener::HandleEvent we'd do:
rv = xpc->WrapNative(cx, obj, aEvent, NS_GET_IID(nsIDOMEvent),
getter_AddRefs(wrapper));
where |obj| was the JSObject for the target.
Now what we do instead is:
rv = mContext->CallEventHandler(mTarget, mScopeObject, funcval, iargv,
getter_AddRefs(vrv));
and CallEventHandler does:
rv = ConvertSupportsTojsvals(aargv, aScope, &argc,
NS_REINTERPRET_CAST(void **, &argv), &mark);
I suspect that the latter call should pass |target| instead of aScope.
![]() |
Assignee | |
Comment 6•19 years ago
|
||
Yeah, that fixes it.
Assignee: general → general
Component: XBL → DOM
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Summary: XBL method trying to use event parameter gets exception → [FIX]XBL method trying to use event parameter gets exception
Target Milestone: --- → mozilla1.9alpha
![]() |
Assignee | |
Comment 7•19 years ago
|
||
Assignee: general → bzbarsky
Status: NEW → ASSIGNED
Attachment #226497 -
Flags: superreview?(jst)
Attachment #226497 -
Flags: review?(mhammond)
Comment 8•19 years ago
|
||
Comment on attachment 226497 [details] [diff] [review]
Like so
sr=jst
Attachment #226497 -
Flags: superreview?(jst) → superreview+
Updated•19 years ago
|
Attachment #226497 -
Flags: superreview?(jst)
Attachment #226497 -
Flags: superreview+
Attachment #226497 -
Flags: review?(mhammond)
Attachment #226497 -
Flags: review+
Comment 9•19 years ago
|
||
Comment on attachment 226497 [details] [diff] [review]
Like so
Er, I screwed up the review flags, but whatever. r+sr=jst for this, even.
Attachment #226497 -
Flags: superreview?(jst) → superreview+
Comment 10•19 years ago
|
||
Ugh, bugzilla conflict handling screwup between my and Mark's reviews. Oh well.
![]() |
Assignee | |
Comment 11•19 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•