nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
In the Browser Toolbox, we fetch all types of targets, including frames and processes.
But the main process target, which is the top level target for the Browser Toolbox,
is also returned by listProcesses and so is reported as duplicated.
Differential Revision: https://phabricator.services.mozilla.com/D51630
--HG--
extra : moz-landing-system : lando
The existing checks were also enabling additional target tracking of the TargetList
for the Browser Content Toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D51783
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
The issue was in commands.js evaluateJSAsync function where
we were trying to use an undefined parameter.
The regression wasn't spotted earlier because we only have
mocha test for CSS warning, and they don't assert this
codepath.
A mochitest is added on this patch to ensure CSS Warnings
can be expanded, that they display the impacted elements
as expected, and that clicking on the icon selects the
expected element in the inspector.
Differential Revision: https://phabricator.services.mozilla.com/D51627
--HG--
extra : moz-landing-system : lando
This method is very asynchronous, called on reflows and throttled. Which means it has a high chance of intermittently failing after destroy.
Differential Revision: https://phabricator.services.mozilla.com/D51663
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
When creating grid and display badges in the markup view, ensure they listen only to their corresponding highlighter events.
Differential Revision: https://phabricator.services.mozilla.com/D51137
--HG--
extra : moz-landing-system : lando
@gl can you take a look at the DevTools test added here?
@nika @mconley I used this.browsingContext.docShell.isContent here to rule out chrome-privileged documents. Do you know if there is better way to check if the current document is chrome-privileged or not?
Differential Revision: https://phabricator.services.mozilla.com/D51320
--HG--
extra : moz-landing-system : lando
This component will help build and maintain the list of all the Targets.
Making it easier to:
* listen for all the targets: TargetList.watchTargets/unwatchTargets,
* iterate over all the existing ones: TargetList.getAllTargets,
* get all the TargetScoped fronts of all the targets: TargetList.getAllFronts.
Differential Revision: https://phabricator.services.mozilla.com/D48857
--HG--
extra : moz-landing-system : lando
Wait for the messages to be displayed, and requestLongerTimeout,
as test failures logs seem to indicate that slower machine take
more than 30s to run the test.
Differential Revision: https://phabricator.services.mozilla.com/D51562
--HG--
extra : moz-landing-system : lando
This makes it possible for the menus to not be constrained
to the panel boundaries if they are taller than the panel
itself (which could be the case for the simulate menu as
it has lots of items).
We need to style the button with a link role in the toolbox
CSS so they don't look like real buttons.
Differential Revision: https://phabricator.services.mozilla.com/D50461
--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
This revision refactors RDM's touch simulator to use modern touch web APIs where possible.
Differential Revision: https://phabricator.services.mozilla.com/D50147
--HG--
extra : moz-landing-system : lando
Since closing D50559, we're not using CSS Grid for the browser's container layout (see D48778 for context). This means positioning the device settings modal using CSS grid areas won't work.
An alternative to this is to contain the RDM toolbar inside the browser stack now that it uses CSS Grid. We can then use absolute positioning to have the RDM toolbar always positioning on top of the browser element and adjust its size when the device settings is opened.
Differential Revision: https://phabricator.services.mozilla.com/D51102
--HG--
extra : moz-landing-system : lando
A new parameter is added, and it expect an array
of filter objects (which contain a pattern and
a label properties), which are going to be used
by the save file dialog.
Depends on D51070
Differential Revision: https://phabricator.services.mozilla.com/D51078
--HG--
extra : moz-landing-system : lando
