As a quick fix to bug 1632918, don't check for app updates until the user
triggers the update intervention. There will still be some jank, but it'll be
postponed until the user types a phrase that triggers the intervention, which is
much better than at the first urlbar use. To avoid the problem where we wouldn't
show an intervention at all the first time the update intervention is triggered
since the updater status in that case will be CHECKING, add an updater listener
to wait for the check to finish and add our result then.
We should look into a better long-term fix, like making the updater's IO async
or not checking for updates at all inside urlbar.
Differential Revision: https://phabricator.services.mozilla.com/D73001
We distinguish between two kinds of pref syntax.
- "Default pref files" are the ones that come with Firefox, constructed from
`all.js` and similar files.
- "User pref files" are the ones that get created in the user's profile.
`prefs.js` is the one that Firefox creates and overwrites every time a pref
changes. `user.js` is the one that users can create themselves.
We also have two basic kinds of pref.
- Default: `pref(...)` and the unfortunate `sticky_pref(...)`.
- User: `user_pref(...)`, which override but don't replace the default.
It only makes sense for user pref files to contain user prefs; users shouldn't
be able to create default prefs or change default pref values.
But it turns out that user pref files have been able to define default prefs
pretty much forever. This appears to be an oversight, and this commit restricts
things so that user pref files cannot contain default prefs.
The commit also fixes an incorrect comment in testParser.js.
Differential Revision: https://phabricator.services.mozilla.com/D73003
Fixes tooltips/menus in responsive design mode. A few accesibility tests
had to be adjusted since tooltips are now automatically created
for them.
Differential Revision: https://phabricator.services.mozilla.com/D72400
This changes the way filter callbacks work in Breakpad so that the
Gecko-provided exception handler can instruct breakpad to just consider an
exception handled and terminate the process without further work. This change
is needed because when two threads enter the exception handler at the same
time the second can get stuck. The logic behind this is convoluted: when the
filter callback "accepts" an exception Breakpad will request minidump
generation and then notify Windows exception search mechanism that the
exception was handled. The process will terminate at this point. However if
a second thread enters the exception handler before this happens it will also
try to handle the exception, either by generating a minidump (prior to my fix
for bug 1434933) or by simply ignoring it (after bug 1434933). However under
both conditions Breakpad will consider the exception not handled and inform
Windows exception search logic to look for another handler. But we're already
at the top-level handler so Windows will try it again, and again, and again
... hanging the process instead of terminating it.
With this patch applied the first time we hit the exception handler we'll
request minidump generation and report the exception as handled. If we hit the
exception handler again we will not request minidump generation but we will
also report the exception as handled so that Windows can terminate the process
right away.
Differential Revision: https://phabricator.services.mozilla.com/D72493
Things that were broken:
- prompts become unreadable when using dark-background lwthemes, because they
keep the window text-shadow (due to the namespace change of tabmodalprompt)
- prompts with long text without word-wrap possibilities
(e.g. `alert("x".repeat(1000))`) cause the text to escape its container.
Differential Revision: https://phabricator.services.mozilla.com/D73131
This ensures that chrome code can always react to the state the browsing
context the parent process observes properly. It's also simpler.
We fix one test that was relying on the event being fired at the
browser. For the same reason as the previous patch in this bug, we can
use resize events instead.
Differential Revision: https://phabricator.services.mozilla.com/D72712
Now that we no longer have the various resolution shenanigans, we really
just want to ensure that child processes observe the resize of the
<browser> element, which can happen just fine if we ensure to flush
layout.
Differential Revision: https://phabricator.services.mozilla.com/D72552
`./mach bootstrap` prepares your environment for a build and installs missing "brew" packages".
However, if a package is installed but out-of-date, it was being ignored by the bootstrapping logic.
This change ensures that `brew update` is run, and updates any out-of-date packages that are requested.
Differential Revision: https://phabricator.services.mozilla.com/D72956
There were a fair number of changes, but the main ones are the switch to
a faster hash (blake3), and to tokio 0.2's faster scheduler.
Differential Revision: https://phabricator.services.mozilla.com/D72960
Update flag comments for "input" flags. These flags are not determined by the
source text generally come from CompileOptions instead. They are preserved on
scripts and stencils to know if bytecode can be reused.
Differential Revision: https://phabricator.services.mozilla.com/D72165
Reorder and renumber the flags. All flag comments are entirely unchanged.
Follow-up patches will update those comments.
Differential Revision: https://phabricator.services.mozilla.com/D72164
mozilla::pkix treats the id-kp-OCSPSigning extended key usage as forbidden
unless specifically required. Client authentication certificate filtering in
gecko uses mozilla::pkix, so before this patch, certificates with this EKU would
be filtered out. Normally this is correct, because client authentication
certificates should never have this EKU. However, there is at least one private
PKI where client certificates have this EKU. For interoperability, this patch
works around this restriction by falling back to requiring id-kp-OCSPSigning if
path building initially fails.
Differential Revision: https://phabricator.services.mozilla.com/D72760
This is a bit of a lateral change but brings consistency with the
FunctionBox. In the future we will fold proper guessed-atom support into
FunctionBox to allow the NameResolver to work without JSFunctions.
Depends on D72997
Differential Revision: https://phabricator.services.mozilla.com/D72998
The name in the FunctionBox should only hold the explicitName rather than any
sort of implicit or guessed name. Note that any other names still on the
function itself will remain set. This seems to be a minor regression
recently, but only in BinAST.
Differential Revision: https://phabricator.services.mozilla.com/D72997
Till now an AudioCallbackDriver, on error state callback, creates a FallbackDriver, which attempts to start the existing AudioCallbackDriver. If the driver has already started this creates a cr
ash because restart is not allowed.
This patch continues using the FallbackDriver, on cubeb state error but the driver has been enhanced with an error state that will not attempt to restart the driver. The fallback driver will continue advancing the graph similar to a ThreadedDriver until a driver switch takes place.
Depends on D73102
Differential Revision: https://phabricator.services.mozilla.com/D73103
The MockCubeb has been reformated to save the latest MockCubebStream. Then a flag is exposed that if true the audio callback will fire a cubeb state change callback with error state and will abort. On top of that, a new unit test has been implemented that triggers the error callback. This results in a crash that is being fixed in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D73102