Closed
Bug 109831
Opened 23 years ago
Closed 23 years ago
DispatchNewEvent cannot occur on anonymous content
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: aaronlev, Assigned: hyatt)
References
Details
(Keywords: access)
Attachments
(1 file)
(deleted),
patch
|
jag+mozilla
:
review+
hewitt
:
superreview+
|
Details | Diff | Splinter Review |
<method name="hoverCell">
<parameter name="aCell"/>
The following code creates an event where the target ends up being the
<colorpicker>, when we really want it to be the individual <spacer> element that
makes up that particular color cell.
<body><![CDATA[
if (this.isColorCell(aCell)) {
this.resetHover();
aCell.setAttribute("hover", "true");
this.mHoverCell = aCell;
+ var event = document.createEvent('Events');
+ event.initEvent('DOMMenuItemActive', false, true);
+ aCell.dispatchEvent(event);
}
]]></body>
</method>
The screwed up sequence:
nsEventStateManager::DispatchNewEvent() calls
target->HandleDOMEvent(mPresContext, innerEvent, &aEvent, NS_EVENT_FLAG_INIT,
&status);
nsXULElement::HandleDOMEvent() subsequently runs the following lines, which
clear the old event and it's target:
nsIDOMEvent* domEvent = nsnull;
if (NS_EVENT_FLAG_INIT & aFlags) {
aDOMEvent = &domEvent;
Eventually as the event bubbles up, it is retargeted, but never to the correct
original target.
If we call HandleDOMEvent without the NS_EVENT_FLAG_INIT, everything works - but
I'm not sure what side effects that has with freeing memory.
Why is the target set and then subsequently cleared and not reset?
Reporter | ||
Comment 1•23 years ago
|
||
The javascript code above is from my patch for bug 109221, in colorpicker.xml.
Anyay, I have verified that the event is originally targeted on the anonymous
content, but ends up being set on the <colorpicker> instead. GetOriginalTarget()
needs to give me the correct original target.
Severity: normal → blocker
Keywords: access
Assignee | ||
Comment 3•23 years ago
|
||
Comment 4•23 years ago
|
||
Comment on attachment 57564 [details] [diff] [review]
Fix HandleDOMEvent in XULElement.
r=jag
Attachment #57564 -
Flags: review+
Comment 5•23 years ago
|
||
Comment on attachment 57564 [details] [diff] [review]
Fix HandleDOMEvent in XULElement.
sr=hewitt
Attachment #57564 -
Flags: superreview+
Assignee | ||
Comment 6•23 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 7•23 years ago
|
||
Thanks, this fixed my problem.
Updated•23 years ago
|
QA Contact: madhur → rakeshmishra
Updated•22 years ago
|
QA Contact: rakeshmishra → trix
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•