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
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
Depends on D51054
Summary of the changes here:
- move DOMHelpers.jsm to dom-helpers.js
- remove all unused methods
- converted to a static helper to avoid instanciating DOMHelpers objects for no reason
- updated call sites accordingly
Differential Revision: https://phabricator.services.mozilla.com/D51065
--HG--
rename : devtools/shared/DOMHelpers.jsm => devtools/shared/dom-helpers.js
extra : moz-landing-system : lando
Depends on D50466
reject-some-requires only supports require/lazyRequireGetter at the moment
We still have a few call sites for lazyImporter, even though they probably should be
migrated to lazyRequireGetter IMO.
Differential Revision: https://phabricator.services.mozilla.com/D50465
--HG--
extra : moz-landing-system : lando
Since I started using this helper in devtools/server/ (Node actor), the file needs to move outside of devtools/client
Differential Revision: https://phabricator.services.mozilla.com/D51053
--HG--
rename : devtools/client/shared/DOMHelpers.jsm => devtools/shared/DOMHelpers.jsm
extra : moz-landing-system : lando
A test is added to ensure isClassConstructor has the expected
value for ES6 class grips.
Differential Revision: https://phabricator.services.mozilla.com/D50962
--HG--
extra : moz-landing-system : lando
Depends on D50466
reject-some-requires only supports require/lazyRequireGetter at the moment
We still have a few call sites for lazyImporter, even though they probably should be
migrated to lazyRequireGetter IMO.
Differential Revision: https://phabricator.services.mozilla.com/D50465
--HG--
extra : moz-landing-system : lando
Depends on D50605
All the traits removed here are not checked anywhere in the codebase.
There is more cleanup to do around old traits that are no longer relevant for backward compatibility, but that might still be used for feature detection.
Differential Revision: https://phabricator.services.mozilla.com/D50616
--HG--
extra : moz-landing-system : lando
The LongStringClient is removed and we replace its
usage with LongStringFront instead.
This require a few variable/function renaming, as
well as updating the mocks we use in node tests.
Switch usage to LongStringFront instead.
Differential Revision: https://phabricator.services.mozilla.com/D50579
--HG--
rename : devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/long-string-client.js => devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/string-front.js
rename : devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/component/create-long-string-client.js => devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/component/create-long-string-front.js
extra : moz-landing-system : lando
We take this as an opportunity to revisit the cache mechanism
for longStrings in object/utils.js (searching through pool
children instead of maintaining a cache object).
This means we had to implement poolChildren in the ActorPool.
A test is removed as it tested this specific actor,
and we have tests for the new LongStringActor.
Differential Revision: https://phabricator.services.mozilla.com/D50460
--HG--
extra : moz-landing-system : lando
Depends on D49940
To support this feature we perform two main changes
- the node actor exposes a getAllSelectors method, and the inspector now stores all selectors rather than just one
- the node actor exposes a waitForFrameLoad method, and the walkerFront findNodeFront helper uses it to make sure frames are loaded before querying a selector
Also added a test
Differential Revision: https://phabricator.services.mozilla.com/D49941
--HG--
extra : moz-landing-system : lando
Cleanup before adding more content to the walker front
Differential Revision: https://phabricator.services.mozilla.com/D49938
--HG--
rename : devtools/shared/fronts/inspector.js => devtools/shared/fronts/walker.js
rename : devtools/shared/specs/inspector.js => devtools/shared/specs/walker.js
extra : moz-landing-system : lando
This adds a color scheme simulation toggle button in the rules view,
which will toggle between 4 different states: default, dark, light,
and no-preference.
This feature is currently hidden away under a preference:
devtools.inspector.color-scheme-simulation.enabled
The final UI/UX still needs to be figured out, however, this initial step is
to land the ability to prototype this feature.
Differential Revision: https://phabricator.services.mozilla.com/D49833
--HG--
extra : moz-landing-system : lando
Depends on D50453
Initially planned to simply add dummy English only string, eg "Paused" but considering that the buttons are also broken, I think the best move for now is to skip the higihlighter when we detect that we don't have the client files. Maybe in the long run we want an easy way to know that we are debugging a mobile device to show a different UI in this highlighter.
Differential Revision: https://phabricator.services.mozilla.com/D50454
--HG--
extra : moz-landing-system : lando
"devtools/client/shared/locales" does not exist and only worked because l10n.js tries to fallback on devtools/client/locales/
Differential Revision: https://phabricator.services.mozilla.com/D50453
--HG--
extra : moz-landing-system : lando
This adds a color scheme simulation toggle button in the rules view,
which will toggle between 4 different states: default, dark, light,
and no-preference.
This feature is currently hidden away under a preference:
devtools.inspector.color-scheme-simulation.enabled
The final UI/UX still needs to be figured out, however, this initial step is
to land the ability to prototype this feature.
Differential Revision: https://phabricator.services.mozilla.com/D49833
--HG--
extra : moz-landing-system : lando
This adds a color scheme simulation toggle button in the rules view,
which will toggle between 4 different states: default, dark, light,
and no-preference.
This feature is currently hidden away under a preference:
devtools.inspector.color-scheme-simulation.enabled
The final UI/UX still needs to be figured out, however, this initial step is
to land the ability to prototype this feature.
Differential Revision: https://phabricator.services.mozilla.com/D49833
--HG--
extra : moz-landing-system : lando
The object-client.js file is now a proper protocol.js front,
but is still named after a client.
This is confusing, so we rename and move the file next to other
fronts, and update all consumers to the new terminology.
Differential Revision: https://phabricator.services.mozilla.com/D49878
--HG--
rename : devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/object-client.js => devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/object-front.js
rename : devtools/shared/client/object-client.js => devtools/shared/fronts/object.js
extra : moz-landing-system : lando
This is where it should have been in the first place. Those attributes belong there.
Differential Revision: https://phabricator.services.mozilla.com/D49577
--HG--
extra : moz-landing-system : lando
Jason Laster
Dorel Luca
Brendan Dahl
Nicolas Chevobbe
Brian Hackett
Gijs Kruitbosch
Ciure Andrei
Micah Tigley
Brad Werth
Alexander J. Vincent
Julian Descottes
Daisuke Akatsuka
Kashav Madan
Gurzau Raul
Jan Odvarko
Emilio Cobos Álvarez
jaril
Ehsan Akhgari
Gabriel Luong
Alexandre Poirot
Jean-Yves Avenard