The patch to bug 1979546 refactored the logic that awaits the process
termination. The logic that processes process termination should stop
the poll loop() via updatePollEvents(). This did not happen, because
updatePollEvents() considered a process alive if it is in
`io.processes`, but the updatePollEvents() was not called when
`cleanupProcess` cleared the last reference.
Consequently, the poll loop continued forever if the process's pipes
closed before the process.
Original Revision: https://phabricator.services.mozilla.com/D261060
Differential Revision: https://phabricator.services.mozilla.com/D266338
The current WaitForMultipleObjects-based implementation causes a
deadlock if 16 or more processes are spawned, as explained in the bug.
This patch replaces the use of events and WaitForMultipleObjects with
I/O Completion Ports (IOCP) as the mechanism to monitor I/O progress
and process terminations. This is not subject to the
MAXIMUM_WAIT_OBJECTS (64) limit of WaitForMultipleObjects.
Original Revision: https://phabricator.services.mozilla.com/D258968
Differential Revision: https://phabricator.services.mozilla.com/D266337
- Updated `Cargo.toml` to point to the app-services commit with the fix
- Reverted my default rust to `1.86.0`
- Ran `./mach configure` and `./mach vendor rust`
Differential Revision: https://phabricator.services.mozilla.com/D266197
CanvasTranslator::RemoveTexture delayed the call to RemoveDrawTarget till all keepalives are
gone. However, this may take place long after RecordedTextureDestruction actually called
RemoveTexture. This gives time for subsequent DrawTargets with the same ReferencePtr to be
created, causing the wrong DrawTargets to be removed.
This patch ensures that when RemoveTexture is called from a RecordedTextureDestruction event
that the DrawTarget is always removed then and there, rather than waiting.
Differential Revision: https://phabricator.services.mozilla.com/D265867
CanvasTranslator::RemoveTexture delayed the call to RemoveDrawTarget till all keepalives are
gone. However, this may take place long after RecordedTextureDestruction actually called
RemoveTexture. This gives time for subsequent DrawTargets with the same ReferencePtr to be
created, causing the wrong DrawTargets to be removed.
This patch ensures that when RemoveTexture is called from a RecordedTextureDestruction event
that the DrawTarget is always removed then and there, rather than waiting.
Differential Revision: https://phabricator.services.mozilla.com/D265867
The new XPI file has been generated from this PR [1], and signed by the
AMO -dev instance (which uses the nonprod cert). FTR since this add-on
needs a recommendation state, we must add the add-on to the "By Firefox"
promoted group via the AMO admin before getting the version signed.
Before:
```
$ xpidump old.xpi
MANIFEST:
ID : N/A
Version : 2.0
Enterprise: No
RECOMMENDATION:
[Line]
SIGNATURES:
PKCS7:
└── PRESENT / PRODUCTION / SHA-1 / REGULAR ADD-ON
└── Certificates:
└── Common Name (CN): signingca1.addons.mozilla.org
Organizational Unit (OU): Mozilla AMO Production Signing Service
End Date : 2025-04-04T00:00:00Z
└── Common Name (CN): {811d77f1-f306-4187-9251-b4ff99bad60b}
Organizational Unit (OU): Production
End Date : 2030-09-15T16:50:45Z
COSE:
└── PRESENT / PRODUCTION / ES256 / REGULAR ADD-ON
└── Certificates:
└── Common Name (CN): signingca1.addons.mozilla.org
Organizational Unit (OU): Mozilla AMO Production Signing Service
End Date : 2025-04-04T00:00:00Z
└── Common Name (CN): {811d77f1-f306-4187-9251-b4ff99bad60b}
Organizational Unit (OU): Production
End Date : 2030-09-15T16:50:45Z
```
After:
```
$ xpidump new.xpi
MANIFEST:
ID : recommended-line@test.mozilla.org
Version : 3.0
Enterprise: No
RECOMMENDATION:
[Line]
SIGNATURES:
PKCS7:
└── PRESENT / STAGING / SHA-256 / REGULAR ADD-ON
└── Certificates:
└── Common Name (CN): cas-intermediate-amo-ca-staging
Organizational Unit (OU): Mozilla Staging Signing Service
End Date : 2050-12-31T00:00:00Z
└── Common Name (CN): recommended-line@test.mozilla.org
Organizational Unit (OU): Production
End Date : 2035-09-17T07:29:49Z
COSE:
└── PRESENT / STAGING / ES256 / REGULAR ADD-ON
└── Certificates:
└── Common Name (CN): cas-intermediate-amo-ca-staging
Organizational Unit (OU): Mozilla Staging Signing Service
End Date : 2050-12-31T00:00:00Z
└── Common Name (CN): recommended-line@test.mozilla.org
Organizational Unit (OU): Production
End Date : 2035-09-17T07:29:49Z
```
[1]: https://github.com/mozilla/mozilla-central-test-xpis/pull/15
Differential Revision: https://phabricator.services.mozilla.com/D265576
Use `oneByteOp8` to emit the `REX` prefix for byte registers if needed. This fixes an
issue with our code for `LStringToLowerCase` for certain register combinations/values.
With patches for bug 1986983 this was caught by jit-tests on Win64-debug builds.
Original Revision: https://phabricator.services.mozilla.com/D263972
Differential Revision: https://phabricator.services.mozilla.com/D264208
extensions.json can miss the data_collection field when it was generated
by a Firefox version that did not support it. The implementation did not
account for this, and prevented extensions from updating due to a
runtime error.
This patch fixes the issue by adding a null check, and unit tests for
background updates. The unit test does not exercise the code path of the
"manual update" scenario from the bug, because of complexity and the
fact that its implementation is going to be replaced with the same logic
of the background update check (bug 1974732).
This patch also includes smaller fixups related to this bug and patch:
- https://phabricator.services.mozilla.com/D263925
- https://phabricator.services.mozilla.com/D264372
Original Revision: https://phabricator.services.mozilla.com/D264155
Differential Revision: https://phabricator.services.mozilla.com/D264618
Previously, as seen, I wrote some horrible code. This patch intends to fix the thread safety issue in the permission prompt code for OffscreenCanvas.
For context, with privacy.fingerprintingProtection=True and privacy.fingerprintingProtection.overrides="+CanvasImageExtractionPrompt", when a canvas is read, we randomize the data, and return the randomized data. At the same time, we show a permission prompt asking the user if they want to allow the website to read the canvas data without randomization. It is a non-blocking prompt (i.e. we allow further canvas reads, it just keeps adding the randomization).
We have two types of canvases. HTMLCanvasElement and OffscreenCanvas. The former is used in the main thread, the latter can be used in both the main thread and worker threads.
To ask for permission, we need to communicate with the parent process with the correct window. However, accessing window from a worker thread is not thread safe. We need to dispatch to the main thread to access the window.
Original Revision: https://phabricator.services.mozilla.com/D262475
Differential Revision: https://phabricator.services.mozilla.com/D263138
