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
The thinking in bug 1800213 was that this CFRunLoopRunInMode was no longer
needed as we went from a busy-loop thread model to an event loop based one.
Tests were all green with the change, but it turned out to be CI that had lost
coverage of test_getUserMedia_basicScreenshare.html instead.
Differential Revision: https://phabricator.services.mozilla.com/D174734
