Open Bug 1565205 Opened 2 years ago Updated 2 years ago

Ensure ImageBitmap object whose origin-clean flag is false cannot enter COEP process

Categories

(Core :: Canvas: 2D, enhancement, P2)

enhancement

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.)

Type: defect → enhancement
Priority: -- → P2

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.)

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.

Component: DOM: Core & HTML → Canvas: 2D

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?

Flags: needinfo?(shes050117)

(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.

[1] https://searchfox.org/mozilla-central/rev/428cf94f4ddfb80eebc6028023a7d89eb277791b/dom/base/StructuredCloneHolder.cpp#170

Flags: needinfo?(shes050117)

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.)

Flags: needinfo?(bugmail)
Blocks: 1575501

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.

No longer blocks: resab
Flags: needinfo?(bugmail)

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.

You need to log in before you can comment on or make changes to this bug.