…owell, a=dmeehan

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

…mjs. r=timhuang, a=dmeehan

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

… are any pending events. r=asuth, a=RyanVM

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

…a=dmeehan

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

…TION_121_0b1_RELEASE a=release CLOSED TREE DONTBUILD

…X_121_0b1_RELEASE a=release CLOSED TREE DONTBUILD

…RyanVM

We had previously encountered a driver bug on Mali Valhall GPUs where
invalidating render targets once they are no longer required results
in rendering artefacts. This invalidation was purely an optimization,
which probably doesn't help much on Mali architecture anyway, so we
can workaround the bug by skipping the invalidation. See bug 1787520
for details.

The latest Mali Valhall GPUs are also affected. This patch therefore
applies the workaround to *all* "Mali-G" models apart from a list of
known working ones. This means we will avoid hitting this issue again
when the next generation of GPUs are released. Once ARM move on to the
next family we can see whether it is still affected and update the
code accordingly if required.

Original Revision: https://phabricator.services.mozilla.com/D194063

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

… of content blocking log. a=RyanVM

Original Revision: https://phabricator.services.mozilla.com/D194131

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

…es - r=release-managers,RyanVM

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

…y to avoid keeping image loader alive for unnecessary amount of time r=emilio, a=dmeehan

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

…r=rhunt, a=dmeehan

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

…, a=dmeehan

Use an URL that actually loads, and wait for it, rather than loading an
url that triggers a network error (which we can't wait for) and would
leak the page instead if closed prematurely.

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

…t, a=RyanVM

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

cs -> 1831050dbdb13078c0d45f54c76bd563bc232db9
gn -> 23a00dac424d705c016ada7507145469c3129f10
ia -> a406276ba11bebc9a2d1d37bf56a4cab8c201a9f
lv -> 6ada03bcfecc6e60e29a8d621bcae08a197f695c

…cko-reviewers,kershaw a=test-only DONTBUILD

The test is only intermittent on windows, because the get-ttl
pref makes the record be refreshed which races clearing the DNS
cache. That means that when expecting a TRR IP we may actually get
it from the native lookup refreshing to get the TTL.

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

…X_121_0b2_BUILD1 a=release CLOSED TREE DONTBUILD

…TION_121_0b2_BUILD1 a=release CLOSED TREE DONTBUILD

…rker is idle and could be GCed. r=asuth, a=dmeehan

After this patch, the Worker can be GCed while it is idle for events.

I want to point out the difference from the BusyCount implementation.
Compared to the BusyCount implementation, BusyCount implementation allows the Worker to be GCed during WorkerRunnable execution iff the WorkeRunnable does not modify BusyCount.

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

…low', r=fluent-reviewers,flod,mhughes, a=dmeehan, l10n=flod

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

…X_121_0b2_RELEASE a=release CLOSED TREE DONTBUILD

…TION_121_0b2_RELEASE a=release CLOSED TREE DONTBUILD

…VE file, disregard the channel map. r=azebrowski, a=dmeehan

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

…r=rhunt, a=dmeehan

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

Having the * denominator causes a bug with passkeys

Original Revision: https://phabricator.services.mozilla.com/D193977

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

… mode. r=win-reviewers,gstoll,cmartin a=RyanVM

We don't necessarily even have access to a user-accessible desktop in
headless mode. Opening a file dialog isn't going to work out.

In practice, file-dialog invocations will typically be intercepted by
Puppeteer before they ever get here (see MockFilePicker.sys.mjs), but
that's configuration-dependent. Explicitly check whether we're in
headless mode before proceeding.

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

el -> b5e2814216230dd329ad0be1b472cd5cfaad9a31
en-GB -> 0eaf9678df6e55c0c4bf14df11b5279c0d3a1e99
he -> b01afd3625b6b7ce0dfd9ca910e29cd7408504aa
it -> 91640cf9105f99ac6d0810f8f6ee365bb2ec730b
nl -> db9fe79945936951f3937e4751c8ea50263696db
sl -> f3c34143e68cb9ac6eca93d03ef46396c90474d4
zh-TW -> 9ea112f8a3525f41987669f28ad2929a9abad27b

…es - a=repo-update, r=dmeehan

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

…on the parent thread. r=asuth, a=dmeehan

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

…wn, a=release

This is not really the best fix - ultimately the pinned version should go in a task definition somewhere, I think, and we should even consider pinning in https://searchfox.org/mozilla-central/source/python/mozboot/mozboot/android.py and pinning for even non-Taskcluster users (as we do for the NDK, cmdline tools, etc.)

But this is the safest, quickest fix for the immediate term.

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

…wn, a=release

This is not really the best fix - ultimately the pinned version should go in a task definition somewhere, I think, and we should even consider pinning in https://searchfox.org/mozilla-central/source/python/mozboot/mozboot/android.py and pinning for even non-Taskcluster users (as we do for the NDK, cmdline tools, etc.)

But this is the safest, quickest fix for the immediate term.

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

…roid. r=jfkthame, a=dsmith

Per /etc/fonts.xml, there are now only two `<family lang="ko">` nodes there:

* OneUISansKRVF series
* SECCJK series (but no KR postfix anymore?)

This patch uses One UI Sans KR VF as the replacement as this is newer and is a variable font (tested with https://codepen.io/SaschaNaz/pen/ExrdYXJ)

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

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

ach -> 2ee934e95c1d93839f9ee8970377cd4577433b06
af -> 495615261e4c3585413ff3731e80cffca4d6f520
an -> 386b4325df282e483cde3cc39e26859335e0d655
ar -> 485b1df890719acce9b536d04f249e0bacb6c552
ast -> 28cabae8c2957e818c7ea759f5b68540e63a7e9b
az -> d9b4d86b544dc0c086ad6cdb6dbb5c97fbfc2dc1
be -> 6d03fd727499e33feafd1eb984c6b1df9ca2fe37
bg -> c3a06db6bfbe01aec358085e29b207dd3d6ab536
bn -> ba632ecbc814accaddc8d1ea4d7d676f1a630da6
br -> 2d94da3a3eb8295824ada9adf49aa28fdaafb76f
bs -> 5d2a23cab74d58a992e1e2be4f9811620653f08f
ca -> e2f0505e3bb05aad5092e306493681636e8b07ce
ca-valencia -> f507a46a36593502f9baff6470d3ac79b31adfff
cak -> c7d19608627df83992f0621ba35aca8905b67166
cs -> 58fb876b34e95b7b03e2cba3c071802164ce8922
cy -> 5f3a3b262128a295347d854ee9a2e7d168b4812f
da -> 00fcbee9e8ccd6c3a8a49619eebd8743495037a6
de -> 85ed5bb1b9aa5d0fc499634eab3591535f1891ba
dsb -> c55e0aa6d337b58616b5465ba99020bfb9fea17c
el -> 0d0534a1e9171870178012a1af1ef3f8c92c53b8
en-CA -> b00de19e424870f29ace6a833ef270dee8376882
en-GB -> 29574a1124cd0cd78085a5e7a024842757614784
eo -> c37ddafcf5eb5734db668444376ed2fa96fb050a
es-AR -> bc8e576c60e093d66085983667a2b9e7629f3ef0
es-CL -> 617eae5f8b22553c9ce2f80de2a6b89df2e02517
es-ES -> 4b1d689ea9694b0b5a4f606d7c0b5dbe5b1b564f
es-MX -> 30f1be5fafd12eb5ca70b56cb05662ea28540992
et -> fe09124261ee3e11c142ddf05ab7aab0ddf5e496
eu -> 96aa8eee0006e0157170e7b447634a16d2931911
fa -> 6ae80b2760068e5a660dae17fc716e719e9628de
ff -> e67800fc01b5576a0e96b670be89773d7b69c245
fi -> e1ac780acc599e863124e98952b996a04cef34a0
fr -> 497fd185f9fe2814962f160ed61855b37824018e
fur -> 7b03163343a279df9ae86da52e502cefde7a100a
fy-NL -> eeadc021905e82578784f52d135835831a720a5f
ga-IE -> 1db9876239c551052a3d59df88a6b576ee271567
gd -> 4b85dea934ef10427138e93495b20acdc3ef8022
gl -> 5700336bb3f6cbdb98f38434c97febac0b16e935
gn -> e44fd71a312eb37344a79fd50c1afa5388cd3c05
gu-IN -> a0c3b4ec8e2fb78285b4d9fb10fa3d3138ef3219
he -> 38b9ebed32223ea93d3d96a62d33677a3f459a50
hi-IN -> b2acb29b31eb89f65db1052431eb867940a3a5ae
hr -> 78e475ccc748fda1aa7c468fa0499c02b934885f
hsb -> 8a42274dd611d6a3daced3b061b946899c60a1ad
hu -> 8c86a7fbb71220b5071dbfcff276f0bc91450890
hy-AM -> d853595d5d4c11afc95a65dbde1c3d372787267a
ia -> d1e3424bd83589a2220063da32d246c1f7c80868
id -> c46a0360db3bcc5af4d96107c5c0006a89a54120
is -> bc87d404b3f93736bc2528108ae874154fb92c19
it -> 9cca3b42c2a9f875213d9013aa59e871aceed37c
ja -> b647dcfff5e538ae47d88289c100880badd6ae66
ja-JP-mac -> 5e3bf8f3379ddf97d49944a79ce6116e85533225
ka -> 3d43e2589f84e4ea1f3909496c65a4a42a4b409e
kab -> f5e7ba1bca08b2e2e49c649c7eb24d97591e5250
kk -> 60f9ae3fef4e6a395d6177526062125d16fe4125
km -> c27863997c8769a5631e50a34e491c1db07126e0
kn -> c18f53a708876648a1d0ddf8253337661694d122
ko -> 3c615586a95d32d481aa149f0eece23eb08eba3f
lij -> 02d092f0f3a6907d8d7ae109c89518d398e77935
lt -> 346380105c98907c66276f50b80c77e3945063f1
lv -> 0ea3697876c3926c3c39a05865e34e81755300d7
mk -> a91df981a46673dfe84d4c6a70288c6152b81b73
mr -> 96360223571b005cfb76ef43b9047ada71ca282e
ms -> 8d0c28a2c50ec81104bea31c5102bb0b1428aa16
my -> d242e89a1d3cf6e1a51a698ec841b2d8d2137fc3
nb-NO -> 6a63e3dce62fcb15426f8c5789097cd7075d2c6a
ne-NP -> 95ba8a76277c03e39c8df753dbbf549d38990f06
nl -> 232231dc34b34b1123ca509378e162f5905092fa
nn-NO -> 469585ac9ba8141d6af75bbb840cbbce00f407e0
oc -> d9e78640a4777cabde9d8baee446854d21f3c2ea
pa-IN -> 485ec78167aed75713db37baae25013459573b29
pl -> 62d30b463b6d840fe9e91174cf31ba229358644d
pt-BR -> 0fceabf3a31e2e9054e43727b80008d696a9d14d
pt-PT -> d7c57b3da999c5f90c18486fb4881d917f43d623
rm -> 7d3ed9db64a50deaa364135030548fabb31a6fcf
ro -> c00c598b391af79ba087afa7a1f3bc8237ce5094
ru -> ad3c47540183a145ed6c6af5a25d5de75e9186a0
sat -> b2febdf5c4a0d06b42bd07d30520de48de7d21bd
sc -> 84564d191eae228521ffe97e6b80f77016715e4e
sco -> 641f98779350626ea32834efb4cba59977f3c5af
si -> e2abfeffff7fe683d6e5cc8adde41787f62bf9c3
sk -> 6b4050fc74d2723116d9c6e5ba44cfdf66ca1425
sl -> f97c395294cbc86eb4dd1b99af5f1b4b68af3416
son -> cc6a063931b9ea99cbb6cda2b4259829accb6cc5
sq -> ffbed19a7fe6160193cf2fdf4e056fa822c7ec15
sr -> cdf63c60d6dac90fffb6f2f812195bb5ea887a3d
sv-SE -> 1a0b1054b3ec84328563cc3308967c30856367b3
szl -> d11f457257fa07b0563dc58c69010a77021e64e0
ta -> 558c5e8454691cb7df6a51cdb0a2c56e0abe49b2
te -> 5b42d1a49a5d032d8bbdcb00870a522b63965e79
tg -> 1b40c89b97c05cc12d74934a4956c1f9478fb55b
th -> 029e3192fde5833b7ade2193ae0caf647b7a3e82
tl -> ccbfccb75a6ef2f349765ea0617dad8164a1eed6
tr -> 4f086929293449302f22348dd6d9ee329d36add3
trs -> 630c349a700ac879088712cb0bc12eebf75653e3
uk -> a2174e1cf2a9e5ee000524009281f78ad146a1c8
ur -> 0c763ab8bce524ce39e77354282219498b80e21c
uz -> e07da42806a90b9a2ec96f03f0235d65ccfaecfb
vi -> edde11b97d8b94eec38f105ce104269b5776d063
xh -> de920cd9bd6fc40d27f74120a6ba8f8a1092c8c9
zh-CN -> 22635ca034c957358432f4c666624e8c78ff253b
zh-TW -> 6e0c3f00d652194364116b282a040b49e0334431

…om Spain. r=win-reviewers,keeler,gstoll a=RyanVM

This patch blocks UsrDNIeCertStore.dll which was formerly used for
digital signatures in the software packages for spanish ID cards (DNIe).
This DLL is old and produces recurrent crashes for users who have it
installed. The new software packages distribute and use DNIe_P11_x64.dll
instead.

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

be -> d05b3c5f3f636bef1ad506d9a3c1b60bbb505c78
br -> 4b19c989ddf18a4b0b15813cbc4cc3df6424896a
bs -> e9762e946697ae1c63f90918d4e89149bc103ff7
cs -> 27342417ac66ff607fd32972d48cccb942f7a831
de -> 96d15d0f682d3e5f572105f1764979423104a2f4
dsb -> 3902de3d6ceaf5fd67cb682b6b301e676c9e9565
el -> b967588fa31afdcad8c58418699fc4e6c22441b7
es-CL -> 8bef64a5a1fcf372aeb9512979d01deabb2f312b
eu -> f8c06e2b5fc30efd980975034daf85395f0ef556
he -> 4e518ab4100e2332abfd762404874a8314d8e1c3
hsb -> 5751ed44491de372cc301459b1c37a962b902376
ia -> dcde23c562263ed989687398d861fbb36867e2e1
is -> 12c60eb36d3d4c8ef491bf4a1d8c8f1aa4b814df
it -> e8f8c9bac937cd2535980042e2125975ddcca840
kk -> 1e81fe35cc48161147ede29930223d3294a70ab6
ko -> 599dc608481254aac7423cb18e65e9e6787cca7e
nb-NO -> 193a02f97b88ccb113597d572471a394c094d502
nl -> bebac4afd445504ab47b46acb4448b91fbf07b95
oc -> 2acb0ca8d6e4b3ed8f1ca7226150a144b83dab72
ru -> daf8c95d0ebca9a3586645442780854869d772b1
sq -> 63c6a5d66210ce4d7f7cec4ba02e61e376cb2c56
sv-SE -> a1ee9ae6623ebfa03b5deb3e41681835cc8a6970
tg -> 544201d3581a7698c3c11b90bb3b079015a9bc85
uk -> f0daf0c79c3aa745433d163e1d2d00b6903e77f9
zh-CN -> b9f11cac2c7792dfea3ede663a43840b874f04bc

…=RyanVM

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

bs -> 9e617fa6a6a7ef90619bea5a320d92e9ec9053ac
da -> 4a879dd8cac235f307fc392db37f2d793bd4603c
en-GB -> e838a6841a8a80b849f719ce427ea10f65ff3c3a
es-CL -> 1e75679a1578105c1ba850f7860231615e9f046c
es-ES -> c8391cdf284f01cbd534584cb808f648844a6e91
fi -> 28438cca75ddfe601322cd1359c76a88e1e43179
fr -> efd8358fb20b633a737e0f7ed60426ac3ac86b24
hy-AM -> b8aa18d38d2ed30f053025b64b9ce841d25f49da
my -> 943585547ec2110623d26148f20f18e1caf49eda
nb-NO -> 5cf0d06986c685dc024aea07d405596120c270f7
nl -> bb1212f778bac3f663745c3c614d84063960695a
pl -> 0c00d6fda799fa331cb2ffc52bf7533f52f56046
rm -> 2280fcc594c73f93d2992ef0e8f9221866c030c8
sk -> 212a8f146248f9f7d1e3d946585db752f532f80f
tg -> 7556c1aa9fc8022eeae95f8a73289a711b1fd4c1
tr -> 509008d470d311b47dd5dfe8a54b0f89feda7536
vi -> 0bfd724ddacd85cae4950be50f16c4f8d14f6f77

…ly builds r=allstarschh a=test-only

This feature is only present in nightly builds.

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

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

…pdate r=RyanVM

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

…=willdurand a=RyanVM

The other labels in the eventPageIdleResult category are reported at
most once every 30 seconds per extension.

The reset_event and reset_parentapicall calls can happen much more
frequently. To avoid the perf issue reported in the bug, stop recording
telemetry with these labels.

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

…X_RELEASE_121_BASE a=release DONTBUILD CLOSED TREE

…daa4980bb9 2b1de81744a329b1b545b79875a9521b16b5ef03| CLOSED TREE DONTBUILD a=release

…X_RELEASE_120_END a=release DONTBUILD CLOSED TREE

… ba=release

…X_121_0_BUILD1 a=release CLOSED TREE DONTBUILD

…sum a=RyanVM

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

…ity delay to expire before clicking the button. r=Gijs, a=RyanVM

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

…. r=ahochheiden, a=release

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

…path. a=RyanVM

Original Revision: https://phabricator.services.mozilla.com/D196069

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

We are seeing severe rendering glitches using the SurfaceControl
rendering path on Samsung S22 devices. This path was added to allow us
to gracefully recover from GPU process crashes on modern Android
versions (See bug 1762424). However, since bug 1824083 we have an
alternative solution to that problem.

Original Revision: https://phabricator.services.mozilla.com/D196169

Depends on D196262

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

We are seeing crashes on the european Samsung S22 family of devices in
eglTerminate after updating to Android 14. To work around this we
deliberately leak the EGLDisplay on affected devices. In practice we
only ever use the default EGLDisplay on Android, and calling
eglInitialize multiple times is allowed, so this is fine.

Note this only occurs when running webgl in the content process, which
will occur naturally following enough GPU process crashes that we
disable the GPU process. When webgl is running in the GPU process
webrender keeps the EGLDisplay alive, meaning we never terminate it.

Original Revision: https://phabricator.services.mozilla.com/D196146

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

…=RyanVM

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

…er optimization on Xclipse 920 GPU. a=RyanVM

In CompositorOGL (used by software webrender on Android) as an
optimization we use glInvalidateFramebuffer rather than glClear for
the color attachment if there is no non-opaque invalid region. This
causes rendering glitches on the Samsung Xclipse 920 GPU. This patch
marks GLfeature::invalidate_framebuffer as unsupported on this GPU,
causing us to fall back to the glClear pach which avoids the glitches.

Original Revision: https://phabricator.services.mozilla.com/D196416

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