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
We should not have a null mScrollContainerFrame in an asr that is in use, but we are getting crashes in bug 1764863 that show that this is happening at volume. We have not been successful over a long period of time of finding a testcase or some way to reproduce. We have a landed patch in bug 1984898 (based on a pernosco of one instance of this from a few years back) that we hope fixes some or most of these. The patch in bug 1984898 is a little bit big, and we have no evidence that it fixes the problem. So I am proposing this patch as something we can uplift that should work around the problem. We still want to fix any instances of that this we come across so the MOZ_DIAGNOSTIC_ASSERT will fire in nightly and early beta builds. The gfxCriticalNoteOnce will alert us if this is having negative consequences later on.
By returning false we will abort the partial display list update and delete the retained display list that contains an asr that has a null mScrollContainerFrame and we will do a full rebuild. This should avoid the problem and be much better than crashing.
Original Revision: https://phabricator.services.mozilla.com/D263224
Differential Revision: https://phabricator.services.mozilla.com/D263820
This allows extensions to access their own content from scripts that they
injected into web pages, without that requested content being automatically
blocked due to failing CORS checks (since the Origin of the request is
the web page).
We have an existing pref 'extensions.content_web_accessible.enabled' whose
'false' value is meant to allow MV2 extensions to access their own resources
from their content-scripts (even if those resources aren't web-exposed). A
recent CORS strictness patch broke this use-case; so this patch relaxes the
strictness, specifically for extensions and specifically when that pref has
the permissive 'false' value.
While we're at it, this patch extends the related xpcshell test cover the case
where the pref is in its default/permissive 'false' configuration (to test the
regression being addressed by this patch), and to test that MV3 is strict under
that configuration. This patch also clarifies the other relevant pref for CORS
principal-selection to avoid implying that it's relevant to WebExtensions
(since it's not anymore).
Original Revision: https://phabricator.services.mozilla.com/D262863
Differential Revision: https://phabricator.services.mozilla.com/D263613
