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)
8.00 KB,
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•22 years ago
|
QA Contact: madhur → rakeshmishra
Updated•22 years ago
|
QA Contact: rakeshmishra → trix
Updated•5 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
•