Ensure ImageBitmap object whose origin-clean flag is false cannot enter COEP process
Categories
(Core :: Graphics: Canvas2D, enhancement, P2)
Tracking
()
People
(Reporter: annevk, Unassigned)
References
(Blocks 1 open bug)
Details
As discussed at https://github.com/whatwg/html/issues/4764 I think we should fail deserialization of ImageBitmap objects whose origin-clean flag is false.
(Somewhat related to bug 1562663 as similar code will have to be touched.)
Updated•6 years ago
|
Reporter | ||
Comment 1•6 years ago
•
|
||
https://github.com/whatwg/html/pull/4734 has a design for solving this issue from the API side. (Review appreciated!) The implementation is likely more involved as we cannot decide when deserializing, but we need to decide when crossing the process boundary. (And this might be even more involved with MessageChannel as a MessagePort can go across various process boundaries before the underlying messaged objects are retrieved.)
Reporter | ||
Comment 2•6 years ago
|
||
Our support for serializing and deserializing ImageBitmap might be lacking somewhat (though I cannot find existing bugs). It fails to work with BroadcastChannel for instance.
Reporter | ||
Comment 3•6 years ago
|
||
https://github.com/web-platform-tests/wpt/pull/18543 has tests. We currently fail both due to not being able to message ImageBitmap in these scenarios. What scenarios do we support messaging ImageBitmap or is there no support?
Comment 4•6 years ago
|
||
(In reply to Anne (:annevk) from comment #3)
https://github.com/web-platform-tests/wpt/pull/18543 has tests. We currently fail both due to not being able to message ImageBitmap in these scenarios. What scenarios do we support messaging ImageBitmap or is there no support?
I'm not familiar with the status for us on the postMessage for ImageBitmap.
However, I am pretty sure we cannot use BroadcastChannel for SharedArrayBuffer even after the pref (javascript.options.shared_memory) is on. Lars added a policy [1] for that when it is going to structured clone an object. So, if imageBitmap has a similar requirement (sharing memory within processes), I believe we don't have a support that yet.
Reporter | ||
Comment 5•6 years ago
|
||
It does not, it has similar requirements to ArrayBuffer
. Andrew, can you take a look? (I realize you have many needinfos, but Andrea has more.)
Reporter | ||
Comment 6•6 years ago
|
||
I had a quick chat with Andrea to answer my questions. As we only support ImageBitmap messaging for window-to-window, window-to-dedicated-worker, and dedicated-worker-to-dedicated-worker it will always be contained within a single COOP+COEP process (or outside of it) and therefore the logic that will be added to the HTML Standard will no-op in Firefox until we fix bug 1575501. That means this does not need to block bug 1477743.
Reporter | ||
Comment 7•5 years ago
|
||
An alternative direction here is to not support serialization of ImageBitmap objects whose origin-clean is false. Yutaka Hirano from Google is pursuing this approach in Chrome (see https://www.chromestatus.com/features/5728790883860480) and we should follow suit if it works out.
Updated•2 years ago
|
Description
•