Closed Bug 1143649 Opened 9 years ago Closed 9 years ago

Add Add/RemoveEventListener to the AnonymousContent API.

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: pbro, Unassigned)

Details

Attachments

(1 file)

The AnonymousContent API has been added through bug 1020244 and its goal is to allow chrome-JS to insert DOM content into a native anonymous container in the canvas frame.

This bug is about adding support to AddEventListener and RemoveEventListener in AnonymousContent.webidl.

The important question here is:

One of the things this API does is prevent the chrome-JS code from accessing the DOM nodes inside the native anonymous container, but adding add/removeEventListener would leak references to these DOM nodes (via event.target and friends).
Then again, the leak already exists today if you add a listener to the browser element and use event.originalTarget.

The use case is:
devtools needs event handling for the things inserted in the page. One concrete example is the GeometryEditor which aims at making elements movable and resizable in content (rather than going through the inspector). See bug 1123851.
Ehsan, you helped me implement bug 1020244. What's your point of view on this?
Flags: needinfo?(ehsan)
Adding these 2 methods doesn't seem too hard.
Do you need access to the Event objects for the events dispatched to these elements, or do you just need to know that the event was dispatched?  If the latter, you can use a simple callback instead of passing an EventListener to these methods.  That way there is no event.target or such to worry about.

If you do need access to the Event objects, then the solution would be a bit more complicated, since you would need to "sanitize" the event objects before passing them to the script handling the event.  The sanitization phase should get rid of anything that points to a Node in the DOM.  But then you would need custom Event objects as well...
Flags: needinfo?(ehsan)
Thanks Ehsan.
Pasting a quick follow-up discussion with Ehsan on IRC:

09:04 < pbrosset> ehsan: I'm fairly sure we'd need access to the event objects, if only to check things like clientX/Y or similar properties
09:05 < ehsan> pbrosset: that's very unfortunate
09:05 < ehsan> pbrosset: cause it means you'd need to do the custom event thing :/
09:06 < pbrosset> ehsan: what do you mean by custom event? Like building a custom object to pass to the handler you mean
09:06 < ehsan> yes
09:06 < ehsan> and custom event objects
09:06 < ehsan> basically you'd need to reinvent the entire event dispatch mechanism :(
09:06 < pbrosset> it indeed sounds like this is what's needed, not sure my c++ skills are up for the task though
09:07 < ehsan> well, it's a sucky solution anyways
09:07 < pbrosset> yeah
09:07 < ehsan> I tried to think of a better one but couldn't really
After more discussions, we decided to continue with the proposal in bug 1139186 (event listener is added at browser level instead).
So, marking this as wontfix for now.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: