Checking the fonts in HelveticaNeue.ttc on macOS Sonoma, both HelveticaNeue-Medium and -MediumItalic have the same weight (500) in their OS/2 table, and return the same value (0.23) for their kCTFontWeightTrait. Back in bug 931426 when the weight override pref was added, we were getting different weights from appKit for these two "Medium" faces, but that no longer appears to be an issue.
This patch makes our CoreTextWeightToCSSWeight mapping a bit more sophisticated, with the added data point of CSS/OpenType weight 500 = CoreText weight 0.23, which we're seeing here in HelveticaNeue. With this refinement in the mapping, we can drop the old override for the HelveticaNeue-MediumItalic face.
Differential Revision: https://phabricator.services.mozilla.com/D197665
- removes `about:firefoxview-next` route
- `about:firefoxview` now points to `firefoxview-next.html` (until we rename)
- remove pref for `browser.tabs.firefox-view-next`
- preserve pref for `browser.tabs.firefox-view-newIcon` as part of firefoxViewNext feature manifest (until experiment is over)
- whitelist unreferenced files in `browser_all_files_referenced.js` as they will be removed in child Bug 1869833
Differential Revision: https://phabricator.services.mozilla.com/D196093
Can be tested locally using this snippet (which I think I took from a test...):
```js
let addonId = "test";
let policy = new WebExtensionPolicy({
name: "Scapegoat",
id: addonId,
mozExtensionHostname: Services.uuid.generateUUID().number.slice(1, -1),
baseURL: "file:///",
allowedOrigins: new MatchPatternSet([]),
localizeCallback() {},
});
policy.active = true;
ProcessHangMonitor.showNotification(window, { addonId, scriptBrowser: { browsingContext: { watchedByDevTools: false }} });
```
Differential Revision: https://phabricator.services.mozilla.com/D194316
Can be tested locally by running this code in the browser toolbox:
```js
gBrowser.selectedBrowser.ownerGlobal.CaptivePortalWatcher._showNotification();
```
Differential Revision: https://phabricator.services.mozilla.com/D194314
There are some tests you can run to see how this looks, but I've also been verifying things locally by running this snippet in the browser toolbox:
```js
const { InfoBar } = ChromeUtils.import(
"resource://activity-stream/lib/InfoBar.jsm"
);
const { CFRMessageProvider } = ChromeUtils.importESModule(
"resource://activity-stream/lib/CFRMessageProvider.sys.mjs"
);
let message = (await CFRMessageProvider.getMessages()).find(
m => m.id === "INFOBAR_ACTION_86"
);
InfoBar.showInfoBarMessage(
BrowserWindowTracker.getTopWindow().gBrowser.selectedBrowser,
{
...message,
content: {
priority: window.gNotificationBox.PRIORITY_WARNING_HIGH,
...message.content,
},
},
{}
);
```
Differential Revision: https://phabricator.services.mozilla.com/D194313
Notification can be triggered locally via this snippet:
```js
BrowserSearch.removalOfSearchEngineNotificationBox("Google", "Foogle")
```
Differential Revision: https://phabricator.services.mozilla.com/D194312
This patch updates the `NotificationMessage` element in `notificationbox.js` so that it extends our newer `moz-message-bar` component instead of the deprecated `message-bar` component. Many of the changes are just dealing with the implications of making things async (so that we can ensure `moz-message-bar.mjs` gets imported). I tried to break out places where I modified related code and tests into separate patches to mitigate some of the review pain here.
This patch solves a longstanding issue where we were loading `in-content/common-shared.css` in the chrome since it gets used by the `message-bar` element. It also makes some small visual changes to our infobars (slight outline, icon colors, adds a bit of spacing).
Differential Revision: https://phabricator.services.mozilla.com/D189872
We only generate a single orderfile and use it for each linked object,
which results in some symbols being listed while not belonging to that
particular object.
Differential Revision: https://phabricator.services.mozilla.com/D197621
The sandbox IPC client/server communication protocol relies on a mutex
that clients can use to check if the broker process is still alive; e.g.
when a response takes more than one second to come. This mutex is owned
by a thread of the broker process and will be marked as abandoned when
that thread dies.
Clients assume that the broker alive mutex being abandoned means that
the whole broker process crashed. Therefore it is necessary that the
thread that owns the broker alive mutex lives as long as the whole
broker process, since clients cannot distinguish between the death of
this thread and the death of the whole broker process.
In upstream code, the broker alive mutex gets created during the first
call to SpawnTarget, which means that it is implicitly required that
this call occurs from a thread that lives as long as the broker process
will. Since we call SpawnTarget from the IPC launcher thread, which dies
during XPCOM shutdown, we are breaking this implicit requirement.
Therefore, this patch makes us create the broker alive mutex from the
main thread, during sandbox initialization. This ensures that clients
will not get disturbed by the death of the IPC launcher thread anymore.
Differential Revision: https://phabricator.services.mozilla.com/D197423
`mach` requires Python 3.7+ since bug 1734402, and Python 3.7 made preserving
dictionary insertion order an official part of the language.
Also use `safe_load` instead of `load` because it doesn't require a loader argument
and is safer (although it doesn't really matter for this use case).
Differential Revision: https://phabricator.services.mozilla.com/D197497
When an extension's content script is very slow and causes a webpage
to hang noticeably, a warning banner is displayed to the user. It
would be useful to also notify the extension developer when that
happens, so that they can address the issue.
Let's add a new event runtime.onPerformanceWarning that can be
dispatched when the browser needs to warn an extension of runtime
performance issues. For now, let's just dispatch that event when the
slow extension warning banner is displayed to the user.
See also https://github.com/w3c/webextensions/issues/456
Differential Revision: https://phabricator.services.mozilla.com/D194708
The reason of introducing this pref was to fix the test failure in bug
1851914 where the PlayReady CDM did not return correct type support on
CI.
In D196509, we already changed our test to make it rely on our mock CDM
so that we don't need to worry about that failure. Therefore, we want to
re-enable this pref in order to get correct type support for PlayReady.
Differential Revision: https://phabricator.services.mozilla.com/D196510
This patch implements most functionalities for Media Foundation ClearKey
CDM, except the decryption part which will be implemented in bug 1870722
because there are still some unknown crashes happening during EME
playback we need to address.
Having this clearkey CDM allows us to start testing EME playback for the
media engine. Currently we only have very limited test coverage for
that.
Differential Revision: https://phabricator.services.mozilla.com/D174991
If the pref is on, we would use Clearkey CDM in the MFCDM process, not
the one in the GMP process. That is only used for testing.
Differential Revision: https://phabricator.services.mozilla.com/D174986
We're going to implement a Media Foundation based ClearKey CDM which
also needs to have same ability of our currnet GMP ClearyKey. In order
to avoid code duplication, this patch move the Clearkey implementation
out from the gmp-clearkey folder, and make them a library for the reuse
purpose.
Differential Revision: https://phabricator.services.mozilla.com/D175434
Most of the time, we don't need to call Document::GetDocumentURI in
nsLayoutUtils::PaintFrame, as it is only used when we are logging or
dumping to the console. We should avoid calling it because this might be
quite large in the case of data URIs and result in OOM crashes. This is
most commonly observed with rasterizing SVG images.
Differential Revision: https://phabricator.services.mozilla.com/D197637
