When we initiate URL bar loads from the parent, loads that are handled externally won't fire a load event from the content process docshell, so we should use the progress listener instead.
Differential Revision: https://phabricator.services.mozilla.com/D67100
Persistent listeners for onMessage and onConnect are special because they
don't have parent EventManagers, so we have a lot of custom code just to keep
track of which extensions have registered them during previous runs.
In this patch, I simplify all that logic to always assume that any extension
which sends messages from content scripts has those listeners setup properly.
The only observable difference is that some poorly written extensions which
were previously broken by delayed startup will now "work" by being started
earlier if a message from a content script arrives during browser startup.
Additionally, unconfuse two different meanings of the "startup" event.
Bonus, avoid some logspam during tests.
Differential Revision: https://phabricator.services.mozilla.com/D70955
When we initiate URL bar loads from the parent, loads that are handled externally won't fire a load event from the content process docshell, so we should use the progress listener instead.
Differential Revision: https://phabricator.services.mozilla.com/D67100
This patch prevents the addon-abuse-report-xulframe custom element from being defined
when AbuseReporter.openDialogDisabled is false (which is the default on all channels
starting from Firefox >= 73).
This change is also preventing the addon-abuse-report-xulframe custom element from
triggering an assertion failure in PresShell::ScrollContentIntoView, which seems to
be due to marionette calling browser.focus() while the custom element has just
injected the browser element that would contain the abuse report panel subframe.
This single-line patch is enough to prevent the assertion failure and still pass
all the existing tests. The addon-abuse-report-xulframe will be removed completely
as part of Bug 1614653.
Depends on D68805
Differential Revision: https://phabricator.services.mozilla.com/D71005
--HG--
extra : moz-landing-system : lando
Since the test goes through all moz.build files disregarding DIRS and
the conditions that may disable directories, in some cases, moz.builds
can fail to be evaluated properly because of missing variables in
config.status. This time (because it's not the first), it's
LLVM_DLLTOOL.
After fixing that, it turns out many of the files/directories pointed to
by Files() directives were removed or moved.
While here, make the test script python3-ready.
Differential Revision: https://phabricator.services.mozilla.com/D70157
--HG--
extra : moz-landing-system : lando
We don't put system addons on the blocklist so there's no need to compute
blocklist state for them. The immediate motivation for this is to avoid
initializing the blocklist early in startup for the initial startup in a
new profile or after a browser upgrade when we're installing/udpating
system and builtin addons.
Differential Revision: https://phabricator.services.mozilla.com/D68443
--HG--
extra : moz-landing-system : lando
This was generated with
```
cp .gitignore .rgignore
rg -l -g '*.{html,xhtml}' 'href="chrome://global/skin/"' | xargs sed -i "" 's/href\="chrome:\/\/global\/skin\/"/href\="chrome:\/\/global\/skin\/global.css"/g'
```
Differential Revision: https://phabricator.services.mozilla.com/D67687
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
We don't put system addons on the blocklist so there's no need to compute
blocklist state for them. The immediate motivation for this is to avoid
initializing the blocklist early in startup for the initial startup in a
new profile or after a browser upgrade when we're installing/udpating
system and builtin addons.
Differential Revision: https://phabricator.services.mozilla.com/D68443
--HG--
extra : moz-landing-system : lando
Cosmin Sabou
Matt Woodrow
Tomislav Jovanovic
Noemi Erli
Stephen A Pohl
Molly Howell
Sebastian Streich
Bingjing Yan
Stefan Hindli
Daniel Varga
William Durand
Tim Nguyen
jayati
Andreea Pavel
Luca Greco
ajitesh
Mark Striemer
Shane Caraveo
Mike Hommey
Narcis Beleuzu
Emma Malysz
Razvan Maries
Andrew Swan
sonakshi
Brian Grinstead
Emilio Cobos Álvarez
Itiel
Sylvestre Ledru