- Patch changes TRRService::MaybeSetPrivateURI so that it doesn't bail
if the URL is invalid. That could lead us into a state where the
network.trr.uri pref has been set to some invalid URL, but we continue
using the previous domain (or even the default TRR provider) instead.
- Updates the DoH settings UI to not set the network.trr.uri pref to "",
as that will cause the TRRService to use the value of
the network.trr.default_provider_uri pref instead.
Differential Revision: https://phabricator.services.mozilla.com/D174111
- The patch saves the confirmation channel's status and skipReason in the TRR Service
- The UI queries the status and displays the stringified version in the Not Available (reason) label
- Introduces doh-status-label CSS rule so the Learn-More link isn't off center
Differential Revision: https://phabricator.services.mozilla.com/D174110
The new form autofill targeting attributes use an actor that may not be
registered in regions where neither credit card nor address autofill is
supported. In that case, the actor never gets registered, and requesting
an unrecognized JSActor throws an exception, which causes JEXL
evaluation to fail, ultimately causing message requests to fail. The
simplest fix is to just catch the exception and report 0 for targeting.
Using an actor externally isn't ideal, but in this case it's
conventional and the alternative - importing the storage object - isn't
great either.
Differential Revision: https://phabricator.services.mozilla.com/D174447
This should make it possible to send data without copying in some
situations.
This requires adding the `rightconst` attribute to the C++ `Type` type
in order to allow specifying `Span<PFoo* const>`, which isn't possible
to specify with a left const. The type is getting very gross with all of
these flags and it's probably worth switching it to be a recursive
type at this point.
Differential Revision: https://phabricator.services.mozilla.com/D173570
Since landing bug 1823411 we have been receiving crash reports on a
variety of Mali-T devices when attempting to compile the brush_blend
shader. This appears to be due to changing v_color_mat to mediump,
though the reason why that crashes is currently unknown. This patch
reverts it to highp to avoid the crash.
This is being landed as-is due to being so late in the cycle, in order
to prevent crashes making it to beta. Further work should be to
determine precisely what conditions cause the crash, and add a test to
ensure we do not encounter it again.
Differential Revision: https://phabricator.services.mozilla.com/D174722
Leaving out the testcase, because the existing one is enormous and fragile. I tried for a while to get a decent testcase, but it's very sensitive to the order of memory allocations, and I couldn't reduce it to anything reasonable. I verified in rr that we enter NewFakeLoopPredecessor with plenty of ballast and use it all up allocating fake defs for ~140 phis.
Differential Revision: https://phabricator.services.mozilla.com/D174684
This is the first step to listen to other AddonManager events. We likely
need a new delegate because there is no other existing delegate we can
leverage I think.
In Fenix, we could use this new delegate like this:
```diff
diff --git a/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/GeckoEngine.kt b/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/GeckoEngine.kt
index 5d34a952e8..8031bd1f67 100644
--- a/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/GeckoEngine.kt
+++ b/android-components/components/browser/engine-gecko/src/main/java/mozilla/components/browser/engine/gecko/GeckoEngine.kt
@@ -357,8 +357,15 @@ class GeckoEngine(
}
}
- runtime.webExtensionController.promptDelegate = promptDelegate
+ val addonManagerDelegate = object : WebExtensionController.AddonManagerDelegate {
+ override fun onDisabled(extension: org.mozilla.geckoview.WebExtension) {
+ webExtensionDelegate.onDisabled(GeckoWebExtension(extension, runtime))
+ }
+ }
+
+ runtime.webExtensionController.setPromptDelegate(promptDelegate)
runtime.webExtensionController.setDebuggerDelegate(debuggerDelegate)
+ runtime.webExtensionController.setAddonManagerDelegate(addonManagerDelegate)
}
/**
@@ -422,7 +429,6 @@ class GeckoEngine(
runtime.webExtensionController.disable((extension as GeckoWebExtension).nativeExtension, source.id).then(
{
val disabledExtension = GeckoWebExtension(it!!, runtime)
- webExtensionDelegate?.onDisabled(disabledExtension)
onSuccess(disabledExtension)
GeckoResult<Void>()
},
```
Differential Revision: https://phabricator.services.mozilla.com/D173835
This patch adds a check for the pref `network.http.windows-sso.container-enabled.{containerID}`.
We also default the pref for the no-container userContextId to true.
Differential Revision: https://phabricator.services.mozilla.com/D174751
This patch replaces "custom" underlying type definitions with definitions gleaned using the std::underlying_type mechanism. This allows us to directly set the underlying type for the enums without having to name it, and reduces the number of semantically identical names in the profile buffer code.
Differential Revision: https://phabricator.services.mozilla.com/D174260
I was able to hit an intermittent failure which looked the same as the one that seems to be hit in the most recent
intermittent failures for this test on a windows system, mainly when I was also keeping the cpu busy enough along
with running this xpcshell tests with --verify.
The failure seems to be due to a race between the assertion on the number of promises still listed in the
Set and the previously pending promise to be rejected and then removed from the Set.
Awaiting the rejected promise first prevented the intermittent failure to be reproduced locally and so it
seems worth landing the same change to confirm that the intermittent hit on the build infrastructure is
going to be prevented by that same small tweak on the test side.
Differential Revision: https://phabricator.services.mozilla.com/D174473
Test-only change to expand coverage:
- Rules without "resourceTypes" do not block main frames by default.
This was desirable because otherwise we could not be simulating
fetch() requests from specified origins.
However, it also meant that we lacked test coverage that verified
that we wouldn't be blocking the main frame.
Now we have that: dnr_ignores_css_import_at_restrictedDomains.
- While I am at it, I also added extra test coverage for the case
where the triggering principal is NOT a restricted domain. While
the implementation works as desired, there was no explicit test
case for this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D174503
Err, so the original patch is necessary but not sufficient, and I
clearly goofed my testing (I had removed this attribute in a separate
commit).
The issue is that this button ends up with a markup like:
<button class="permission-popup-permission-remove-button">
<label flex="1" class="permission-popup-permission-state-label">Allowed Temporarily</label>
<hbox class="box-inherit button-box" align="center" pack="center" flex="1" anonid="button-box">
<image class="button-icon"/>
<label class="button-text"/>
</hbox>
</button>
So the label and hbox divide the available space in half. Removing any
of the flex="1" attributes would cause the desired rendering.
I don't think the hbox needs to be flexible tbh, but ok, that's a
riskier change. I'm pretty sure the label in this case doesn't need to
be flexible at all though, specially since we don't want these buttons
to take any minimum amount of space.
An alternative would be to use `flex: 1 auto` or so for the label (via
CSS). That'd match the pre-regression behavior more exactly, but again I
don't think flexing the label is needed at all.
Depends on D174706
Differential Revision: https://phabricator.services.mozilla.com/D174707
The previous patch removed some MIR instructions from `WarpBuilder::buildCallObject`,
because storing aliased arguments to the call object now happens with bytecode
instructions. Unfortunately that means we lost some optimizations baked into
`buildCallObject` to elide GC barriers.
This patch adds an optimization pass to optimize the MIR instructions we generate for
the new bytecode sequence in a similar way to what we did manually in `buildCallObject`.
In the future we could use this to optimize other allocation instructions as well.
Differential Revision: https://phabricator.services.mozilla.com/D174631
Emit bytecode in the prologue to initialize the slots for closed-over arguments, instead
of doing this at runtime.
This is faster in the interpreter and Baseline because we no longer have to look
at the scope's bindings each time we allocate a call object. It also makes it easier
to optimize the `CallObject` allocation later.
Differential Revision: https://phabricator.services.mozilla.com/D174579
Valentin Gosu
Kershaw Chang
Katherine Patenio
Julian Descottes
Shane Hughes
Dan Minor
Bryan Thrall
Nika Layzell
Jamie Nicol
Lee Salzman
Victoria Ajala
Mark Banner
Angel_V129
Tom Schuster
Iain Ireland
Mike Conley
serge-sans-paille
William Durand
Mike Kaply
Hannah Peuckmann
Dale Harvey
Manuel Bucher
Niklas Baumgardner
Adam Brouwers-Harries
Luca Greco
Rob Wu
Greg Stoll
Greg Tatum
Emilio Cobos Álvarez
Jan de Mooij