Allow sending CPOWs over JSWindowActor via sendAsyncMessage
Categories
(Core :: DOM: Content Processes, task, P2)
Tracking
()
People
(Reporter: mconley, Assigned: jdai)
References
Details
I know what you're thinking - CPOWs? That's a terrible idea! And we stopped using those years ago! And you're right. Well, kinda.
We still use CPOWs in Firefox, but in a very particular way: we never access members of CPOWs, but we use them as cross-process handles for DOM nodes.
As an example, if I were to right click on an image, the <img> node would be passed as a CPOW through the contextmenu message sent to the parent. The parent would never attempt to access any members of that CPOW, but would eventually send another message back down to content passing that CPOW back.
In the content process that the CPOW came from, that'd resolve back into the DOM node. It's really handy to be able to have a unique handle for a DOM node be process-portable like this.
Currently, we can't pass CPOWs over JSWindowActor's sendAsyncMessage. I've been trying to come up with a way of getting the same behaviour that I need here without using CPOWs, but I'm hard-pressed to.
Originally, I thought I could do this by having a mapping from UUID to a weak reference to the DOM node exist in the content process where the node lives, but that implies that there's a point at which the UUID will be revoked - otherwise, we have an ever-growing list of weak references that never gets smaller.
Talking with mccr8 and nika, using the old CPOW machinery might be easier.
|
||
Comment 1•5 years ago
|
||
Yeah, there's lots of weird edge cases to deal with, and the existing machinery deals with it, and frontend people seem to be okay with what it provides, so I think we should just use the existing stuff. If nobody accesses properties, then maybe the features of CPOWs could be trimmed down, but that sounds like an orthogonal thing.
|
||
Updated•5 years ago
|
|
Assignee | |
Updated•5 years ago
|
|
Reporter | |
Comment 2•5 years ago
|
||
Hi jdai,
I may have just come up with an alternative mechanism / workaround which might mean we can avoid sending CPOWs like this.
Effectively, it's to have a JSM in each content process have a weak mapping from BrowsingContext to a mapping of uuid to DOM node weak references. This means that we only risk leaking uuid / weak references for the lifetime of the BrowsingContext. We can also add a method for revoking the uuid's.
So maybe hold off on implementing this just now until I get a chance to sketch this out and consult with Neil on it on Monday.
|
|
Reporter | |
Comment 3•5 years ago
|
||
My workaround appears to work, so I'm going to close this out as WFM. I'm sorry if you'd already started on this! Feel free to re-open if it turns out we actually do need to send CPOWs over the JS Window Actors for other reasons, but for now, front-end no longer needs this.
Description
•