Differential Revision: https://phabricator.services.mozilla.com/D153397

This patch contains the bulk of the implementation of the modal. Most of
it is UI work and wiring together the various components. There is a bit
of complexity in the clustering algorithm, as I implemented the DBSCAN
algorithm to help cluster the text recognition results.

I filed Bug 1782586 to improve the DBSCAN algorithm, but currently it
works the same as the algorithm is described on Wikipedia.

Note that the tests are in the following patch in order to keep the line
count small for this patch.

Differential Revision: https://phabricator.services.mozilla.com/D153396

The implementation follows after this, but I felt it made the code
easier to read to by splitting it out.

Differential Revision: https://phabricator.services.mozilla.com/D153395

Bug 1782578 - Rename and move the context menu for text recognition r=nordzilla,fluent-reviewers,flod

This matches what is in the Figma spec.

Differential Revision: https://phabricator.services.mozilla.com/D153394

This code will most likely be removed, but for now I am putting it
behind a pref so that it won't be activated when the modal is being
created.

See Bug 1782582 for the removal of the code.

Differential Revision: https://phabricator.services.mozilla.com/D153393

* Enable testing using Ion
* Disable call_ref.js for ion
* Allow Ion when --wasm-function-references
* Fix WasmOpIt to pass ref values
* Add br_on_null, br_on_non_null, ref.as_non_null

Differential Revision: https://phabricator.services.mozilla.com/D154146

I think that this issue was introduced by another series of patch (when we started passing nsACStrings as parameter in the bindings), but were hidden by unified builds.

Differential Revision: https://phabricator.services.mozilla.com/D154247

Differential Revision: https://phabricator.services.mozilla.com/D152521

Differential Revision: https://phabricator.services.mozilla.com/D152520

Depends on D152082

Differential Revision: https://phabricator.services.mozilla.com/D152093

Depends on D152081

Differential Revision: https://phabricator.services.mozilla.com/D152082

The former frees resources but keeps the handle. It can be called multiple times. The latter destroys the handle. Any subsequent reference to the same buffer is a bug and will cause the GPU process to crash.

Depends on D152080

Differential Revision: https://phabricator.services.mozilla.com/D152081

Depends on D151703

Differential Revision: https://phabricator.services.mozilla.com/D152080

Depends on D151702

Differential Revision: https://phabricator.services.mozilla.com/D151703

The error is handled in the callbacks.

Depends on D151701

Differential Revision: https://phabricator.services.mozilla.com/D151702

Depends on D151632

Differential Revision: https://phabricator.services.mozilla.com/D151701

Having the code in the same place makes it easier to follow. This made me realize that the validation of aMode in mapAsync has to move to the device side (fix coming in a followup).

Depends on D151631

Differential Revision: https://phabricator.services.mozilla.com/D151632

Another cosmetic change. I've dabbled with IPDL actors too much to not think about WebGPUParent when reading "mParent". Also the parent-child relationship between Device and Buffer is not very obvious to me (nor is it part of the specification).
So I find that wrapping mParent in a GetDevice method to make the code easier to understand. It also makes it explicit that the parent pointer cannot be null.

Depends on D151630

Differential Revision: https://phabricator.services.mozilla.com/D151631

It is not used anywhere.

Depends on D151629

Differential Revision: https://phabricator.services.mozilla.com/D151630

Make sure to always clean up any potential content-side state and only avoid sending Destroy each time.

Depends on D151621

Differential Revision: https://phabricator.services.mozilla.com/D151629

Per spec, if a buffer is mapped in destory(), unmap() must be called.

Depends on D151620

Differential Revision: https://phabricator.services.mozilla.com/D151621

Depends on D151619

Differential Revision: https://phabricator.services.mozilla.com/D151620

Per spec (and discussion with someone on the chromium side where spec is vague), the correct behavior should be:
 - MapAsync validation happens on the device timeline, so we should reject the promise in mapAsync on the content side if we run into an internal error not described by the spec.
 - Unmap immediately rejects all pending mapping promises on the content side (there can be multiple of them since we have to catch that error on the device timeline).

This patch tracks a single mapping promise at a time and immediately rejects on the content side any subseqent mapping
request made until unmap is called. This means our current implementation deviates slightly from the current state of
the spec in that:
 - The promise is rejected earlier on the content timeline,
 - If the first request fails, all subsequent requests will fail until either unmap or when the content side receives and processes the rejected
   promise, whereas Dawn's implementation would allow the first valid request to succed.

There was some confusion around the the use of uint64_t and size_t which probably originated at point where this code was working differently. This patch uses uint64_t (=BufferAddress) more consistently removing the need for some of the casting and overflow checks.
One notable change in the overall logic is that SetMapped is now called when the buffer is actually in the mapped state (before this patch it was called as soon as the buffer had a pending map request).

Depends on D151618

Differential Revision: https://phabricator.services.mozilla.com/D151619

Depends on D151617

Differential Revision: https://phabricator.services.mozilla.com/D151618

No funcitonal change here, I like to have the code maintaining and depending on the same invariants to be in the same place.

Depends on D151616

Differential Revision: https://phabricator.services.mozilla.com/D151617

This commit makes WebGPU buffers use unsafe shmems.
Instead of relying on moving the shmem back and forth between the two processes to ensure thread safety, we instead rely on the validation done on both sides. The upside is that it makes it much easier to implement said validation correctly.

In the interest of splitting the buffer mapping rework into small-ish commits, this one puts some structural pieces in place but doesn't necessarily do justice to the final implementation:
 - The validation itself is coming in subsequent patches in this series.
 - Mapping sub-ranges of the buffer was somewhat implemented in some parts of the parent code and not in others, and was fairly broken as a whole. This commit always maps the entire buffer and proper logic for sub-ranges is coming in another commit.

The main things this commit does put in place:
 - Each mappable buffer is associated with a Shmem that is accessible to both sides.
 - On the child side, if a buffer is not mappable, then Buffer::mShmem is in its default state (it doesn't point to any shared memory segment).
 - On the parent side, if a buffer is not mappable it does not have an entry in mSharedMemoryMap.
 - The shmem is always created by the child and destroyed by the parent.

Depends on D151615

Differential Revision: https://phabricator.services.mozilla.com/D151616

Also return an empty slice instead of crashing in case of errors.
This is a small piece split off of the buffer mapping rework. Most of the call sites are completely rewritten in followup patches, and error reporting will also come in followups.

Depends on D151374

Differential Revision: https://phabricator.services.mozilla.com/D151615

Depends on D149892

Differential Revision: https://phabricator.services.mozilla.com/D151374

Most operations maniplating shmems in WebGPU are fallible, we'll have to handle passing them conditionally in most messages.

This commit starts with BufferMap, to avoid crashing when map is called on an invalid buffer.

Differential Revision: https://phabricator.services.mozilla.com/D149892

Differential Revision: https://phabricator.services.mozilla.com/D154120

Bug 1783934 - Add a chrome-only -moz-box-layout: legacy | flex, and use that to implement flexbox emulation. r=dholbert

Differential Revision: https://phabricator.services.mozilla.com/D154153

We have unshipped these since forever, no point in keeping the pref
around. Move the relevant tests to chrome ref/mochitests.

Differential Revision: https://phabricator.services.mozilla.com/D154152

Differential Revision: https://phabricator.services.mozilla.com/D153757

Bug 1782677 - Optimize away extra object and function for already-retrieved iterator method in for-of in self-hosted JS. r=jandem

Differential Revision: https://phabricator.services.mozilla.com/D153756

Bug 1783918 - Part 4: Plumb trigger event through to calls to webrtcUI.showSharingDoorhanger and have it call openPopup directly. r=pbz

Differential Revision: https://phabricator.services.mozilla.com/D154130

Bug 1783918 - Part 3: Make it possible for the permission panel anchor and position to be overridden. r=pbz

Differential Revision: https://phabricator.services.mozilla.com/D154129

This also moves the fullscreen fix for bug 1557041 to the top of openPopup so that
direct callers of openPopup don't bypass the fix.

Differential Revision: https://phabricator.services.mozilla.com/D154128

There's already a command event handler on the whole webrtcIndicator window,
so we don't need to set additional ones on the menuitems, as the window handler
is doing the same thing.

Differential Revision: https://phabricator.services.mozilla.com/D154127

This won't be used for any security or routing purposes, but can be useful for
debugging. It will be used in the future by the profiler to correlate sent and
received message events across processes.

Differential Revision: https://phabricator.services.mozilla.com/D153621

Bug 1779792 - Part 4: Deduplicate ProcessChild subclass constructors, r=ipc-reviewers,necko-reviewers,media-playback-reviewers,alwu,mccr8

These constructors are unnecessary and can be defined with a `using` statement,
making it easier to change all constructors simultaneously.

Differential Revision: https://phabricator.services.mozilla.com/D153620