Updating the HSTS preload list is now taking close to the previous limit
of 5 hours, so bump it to 6 hours as a stopgap, and adjust the start
time to keep its end time from going too late in the day.
Differential Revision: https://phabricator.services.mozilla.com/D112346
Migrates two strings to fluent and uses sentence casing.
Places identity security block into a toolbar button.
Fixes margin spacing.
Removes green color from secure connection.
Differential Revision: https://phabricator.services.mozilla.com/D111368
The features rewrite got the names of the Firefox wasm prefs wrong, they
all have a wasm_ prefix that got chopped off. This puts it back.
It sucks that we don't have meaningful test cases for this. A manual
test case (see bug) is easy, but how to automate it?
Differential Revision: https://phabricator.services.mozilla.com/D112325
1. Add task to get and build clang from the main branch.
2. Using clang main toolchain we build on a daily basis linux64 firefox, this tasks also automatically triggers the fetch and build of clang from main branch since we don't cache it.
Differential Revision: https://phabricator.services.mozilla.com/D111063
A `simulateScreenOrientationChange` method is created in targetConfigurationCommand
since we need to reach both the parent process (to call `setRDMPaneOrientation`),
and the content process in some cases (to dispatch an `orientationchange` event).
Another change was needed to ensure the orientation was set early enough in the
document lifecycle: when a new browsing context is created, we want to call
`setRDMPanOrientation` again, to "persist" the orientation. But the method bails
if `browsingContext.inRDMPane` isn't true, which is not the case when we get
the new browsing context.
In such case, we check if `inRDMPane` was true in the previous browsing context,
and we set it again on the new one, before re-applying the configuration.
Since the command needs RDM to be open to be effective, we're not adding a test
directly in the target configuration command folder, but extend an existing RDM
test to cover more cases.
Note that calling `setRDMPaneOrientation` on the browsing context does not apply
the orientation to iframes (See Bug 1704830), which is why we don't test it in
the test.
Differential Revision: https://phabricator.services.mozilla.com/D111989
`ProduceVerifyOutput` takes an `transform_fn_t`, which is a type
definition for `Option<unsafe fn(...)>`.
So we need to pass `Some`. This code can never have worked correctly.
Differential Revision: https://phabricator.services.mozilla.com/D112341
If JavaScript string is UTF-16, we can return error when we cannot allocate
Java string. But if it is Latin-1, GeckoView crashes due to using infallible
version of StringParam.
So we should use fallible version of StringParam instead even if Latin-1.
Differential Revision: https://phabricator.services.mozilla.com/D112176
This property does nothing since bug 315209 got implemented.
Every single user that I checked was doing the same math by hand, so
hooray for good defaults :-)
Differential Revision: https://phabricator.services.mozilla.com/D112253
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
