nsIDOMWindow is now an empty interface. There are two references to
nsIDOMWindow::openDialog in comments which needed to be updated. There
were also a few forward declarations of nsIDOMWindow that were unused.
Differential Revision: https://phabricator.services.mozilla.com/D51738
--HG--
extra : moz-landing-system : lando
Finally, let's move the actual IO away from the main thread.
This means there are now 3 ways of looking for plugins:
1. looking for changes from ReloadPlugins. This runs the PluginFinder runnable
on the main thread.
2. loading plugins from LoadPlugins. This will:
a) first check prefs and report the flash plugin based on that information,
if the prefs indicate it exists (using the callback provided by
nsPluginHost).
b) then hopefully dispatch to a background thread, where it will read
pluginreg.dat, scan the appropriate folders on disk, and see if
anything changed. Once done, it sets mFinishedFinding to true and
re-dispatches itself to the main thread.
c) then on the main thread, it reports any changes to nsPluginHost.
3. if dispatching in 2(b) fails, we will run steps (b) and (c) on the main
thread.
Note: if ReloadPlugins is called, we intiially do (1), but if we find
changes, we clear out the set of known plugins and then run LoadPlugins
again (meaning we go through 2 (or 3 if 2(b) fails)). This is how
reloading plugins worked prior to my changes and I've attempted not to
change it.
In order for this to work, there are some other changes in this commit:
- the sandbox prefs are being read "early" and cached for flash vs
"everything else". We can't access prefs on non-main threads without
using StaticPrefs, which doesn't seem worth it here.
- some of the plugin tag classes are moved to threadsafe refcounting.
This is a bit unfortunate, but because they're instantiated on a non-
mainthread, and then later used on the main thread, despite the
fact that the architecture means nothing tries to touch them from
more than one thread at once, without threadsafe refcounting we hit
asserts in debug mode if we add references to them back on the main thread.
- we add shutdown blocking for pluginfinding. We don't really want to
be halfway through finding plugins and then trying to shut them down,
or re-instantiating plugins after they've been unloaded.
- we keep a reference to the "pending" pluginfinder instance while
doing lookups away from the main thread (ie (2)), to avoid re-entrancy or
trying to write to pluginreg while we're reading it somewhere else,
etc. If there's an attempt to do more plugin finding while this is
ongoing, we flip mDoReloadOnceFindingFinished and do a reload once
our initial lookups are complete.
Depends on D48331
Differential Revision: https://phabricator.services.mozilla.com/D48332
--HG--
extra : moz-landing-system : lando
Finally, let's move the actual IO away from the main thread.
This means there are now 3 ways of looking for plugins:
1. looking for changes from ReloadPlugins. This runs the PluginFinder runnable
on the main thread.
2. loading plugins from LoadPlugins. This will:
a) first check prefs and report the flash plugin based on that information,
if the prefs indicate it exists (using the callback provided by
nsPluginHost).
b) then hopefully dispatch to a background thread, where it will read
pluginreg.dat, scan the appropriate folders on disk, and see if
anything changed. Once done, it sets mFinishedFinding to true and
re-dispatches itself to the main thread.
c) then on the main thread, it reports any changes to nsPluginHost.
3. if dispatching in 2(b) fails, we will run steps (b) and (c) on the main
thread.
Note: if ReloadPlugins is called, we intiially do (1), but if we find
changes, we clear out the set of known plugins and then run LoadPlugins
again (meaning we go through 2 (or 3 if 2(b) fails)). This is how
reloading plugins worked prior to my changes and I've attempted not to
change it.
In order for this to work, there are some other changes in this commit:
- the sandbox prefs are being read "early" and cached for flash vs
"everything else". We can't access prefs on non-main threads without
using StaticPrefs, which doesn't seem worth it here.
- some of the plugin tag classes are moved to threadsafe refcounting.
This is a bit unfortunate, but because they're instantiated on a non-
mainthread, and then later used on the main thread, despite the
fact that the architecture means nothing tries to touch them from
more than one thread at once, without threadsafe refcounting we hit
asserts in debug mode if we add references to them back on the main thread.
- we add shutdown blocking for pluginfinding. We don't really want to
be halfway through finding plugins and then trying to shut them down,
or re-instantiating plugins after they've been unloaded.
- we keep a reference to the "pending" pluginfinder instance while
doing lookups away from the main thread (ie (2)), to avoid re-entrancy or
trying to write to pluginreg while we're reading it somewhere else,
etc. If there's an attempt to do more plugin finding while this is
ongoing, we flip mDoReloadOnceFindingFinished and do a reload once
our initial lookups are complete.
Depends on D48331
Differential Revision: https://phabricator.services.mozilla.com/D48332
--HG--
extra : moz-landing-system : lando
The current implementation of addContentEventListener() is centered
around the message manager. When any message manager goes away, it
cleans up everything, which does not work when Fission is enabled and
we do a cross-process navigation.
My new implementation instead uses window actors. Message manager
shared state is used to store the set of expected event listeners. New
windows, after the function is called for the first time in a test,
will get listeners added properly. Of windows that exist at the first
time the function is called in a test, only windows associated with
the BC of the browser that is passed in will get added, which is a
disadvantage relative to the current setup. That could probably be
fixed.
We auto remove at the end of the test, not when any message manager is
torn down, so there's never a need to disable auto removal.
Differential Revision: https://phabricator.services.mozilla.com/D48777
--HG--
extra : moz-landing-system : lando
This patch converts the certList attribute of nsITransportSecurityInfo
from nsIX509CertList to Array<nsIx509Cert>
Differential Revision: https://phabricator.services.mozilla.com/D48745
--HG--
extra : moz-landing-system : lando
This patch converts the certList attribute of nsITransportSecurityInfo
from nsIX509CertList to Array<nsIx509Cert>
Differential Revision: https://phabricator.services.mozilla.com/D48745
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
The XPInstall content handlers currently make all sorts of assumptions about
the process they're being run in and the docShell their request is tied to.
These assumptions don't hold under Fission, either now, when they may be
called just after a process switch, or in the future, when they'll be called
in the parent process.
This patch updates them to operate on the BrowsingContext of the request, and
to do their messaging via the process message manager, rather than via frame
message managers. As a bonus, it also removes the existing hacks they had in
place to handle the cases where frame message managers didn't work.
Differential Revision: https://phabricator.services.mozilla.com/D48224
--HG--
extra : moz-landing-system : lando
All but browser_bug744745.js seem to pass even without the fixes I
made, which seems odd.
browser_bug1058164.js is a little odd because it passes in {} instead
of a boolean for the useCapture argument. I think this ends up calling
addEventListener(..., {}, false), which should be the equivalent of
addEventListener(..., {}).
Differential Revision: https://phabricator.services.mozilla.com/D49453
--HG--
extra : moz-landing-system : lando
browser_about_debugging_link.js is testing the page options that open (or switch) to about:debugging
from about:addons.
This test seems to be failing intermittently because there are pending RDP requests when the about:debugging
tab is being closed once the test is completed.
We already had a similar issue before and at the time daisuke provided us the test helpers currently used
in the test to wait for the tabs, workers and extensions to be populated in the store.
Unfortunately this doesn't seem enough anymore, especially with fission enabled the test is keep
failing because it seems that some new RDP requests are pending when we are closing the tab
(from the stacktrace it seems that the pending requests are triggered by the "processes updates listener").
The waitForRequestsToSettle test helper used in some other about:debugging tests seems to be able to fix
the intermittent failure (trying on linux64 debug locally it passed test-verify multiple times).
Differential Revision: https://phabricator.services.mozilla.com/D49015
--HG--
extra : moz-landing-system : lando
At this point, fullscreen is not regressed but it doesn't work with oop iframes yet.
Differential Revision: https://phabricator.services.mozilla.com/D35026
--HG--
extra : moz-landing-system : lando
Move test helpers and the common abuse report test cases (the ones that should run in sub-frame and dialog window mode)
into an head_abuse_report.js support file, then run all the common test cases from browser_html_abuse_report.js
(in sub-frame mode) and browser_html_abuse_report_dialog.js (in dialog window mode).
Depends on D45571
Differential Revision: https://phabricator.services.mozilla.com/D46019
--HG--
rename : toolkit/mozapps/extensions/test/browser/browser_html_abuse_report.js => toolkit/mozapps/extensions/test/browser/head_abuse_report.js
extra : moz-landing-system : lando
