Depends on D49303
Some methods from css-logic were extracted from the devtools codebase to be used by context-menu files.
This was only needed in order to compute the css-selectors for Inspect Element.
If we use ContentDOMReference instead, those helpers can move back in the devtools codebase
(leaving them in css-selector.js fails the all-files-referenced test for some reason as well)
Differential Revision: https://phabricator.services.mozilla.com/D49330
--HG--
rename : toolkit/modules/tests/chrome/test_findCssSelector.html => devtools/shared/tests/mochitest/test_css-logic-findCssSelector.html
extra : moz-landing-system : lando
Depends on D49941
Using ContentDOMReference instead of creating an array of selectors makes inspect element more stable in case the page is modified between after the contextmenu opens.
It will also make the feature easier to make fission compatible
Differential Revision: https://phabricator.services.mozilla.com/D49303
--HG--
extra : moz-landing-system : lando
Increase stability by replacing the arbitrary timeouts with waiting for the DOM.
Differential Revision: https://phabricator.services.mozilla.com/D50844
--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
We try to lazy load all the things we know we might
not need directly when opening the console.
Differential Revision: https://phabricator.services.mozilla.com/D50800
--HG--
extra : moz-landing-system : lando
This patch ensures we get the cached messages
before setting the event listeners so we don't
risk having duplicated messages (coming from both
cache and event).
Differential Revision: https://phabricator.services.mozilla.com/D50602
--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
Depends on D49939
Small fix on the findNodeFront helper. The walker should be able to calculate its depth without relying on consumers to remove selectors from the array passed to findNodeFront.
Differential Revision: https://phabricator.services.mozilla.com/D49940
--HG--
extra : moz-landing-system : lando
Depends on D49938
This helper can be moved on the walker front and will be useful to find the selected node front after a page reload
Differential Revision: https://phabricator.services.mozilla.com/D49939
--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
Some callers of SpecialPowers.pushPermissions wrapped the call in a
promise. That is not needed; directly use the returned promise instead.
Differential Revision: https://phabricator.services.mozilla.com/D50487
--HG--
extra : moz-landing-system : lando
The change to await snapshotWindow is something that should have been
done in Bug 1573254.
Differential Revision: https://phabricator.services.mozilla.com/D47510
--HG--
extra : moz-landing-system : lando
This helper function awaits the new custom event sent by the RDM pane
frame script when zooming is done, then waits for the reflow to be
complete also. After this is done, resolution and window and content
sizes all have their correct, final values.
Differential Revision: https://phabricator.services.mozilla.com/D47366
--HG--
extra : moz-landing-system : lando
The ZoomChild actor normally caches its full zoom level only when it is
changed, then emits a FullZoomChange event. That event causes problems
with Responsive Design Mode, which receives the event after other
similar events that carry the full zoom level of the RDM pane content.
The RDM UI pane itself always stays at 1.0 zoom. This change makes the
ZoomChild cache its initial fullZoom level as soon as possible, which
prevents the first RDM zoom change from sending the unwanted event.
Differential Revision: https://phabricator.services.mozilla.com/D49793
--HG--
extra : moz-landing-system : lando
This change makes the RDM content frame script listen to the new
PreFullZoomChange event, and treat that as a trigger to save the
existing resolution. The content window will send 2 resize events
as it adjusts to the new RDM pane size set by the front end. After
these events are received, the resolution is restored and a new
event is fired that indicates the work of zooming is complete.
Differential Revision: https://phabricator.services.mozilla.com/D48624
--HG--
extra : moz-landing-system : lando
This is a gross hack, of course, but has the advantage of not breaking sites
that use both zoom and -moz-transform / -moz-transform-origin.
There should be no behavior change when the pref is off, of course, and the
webcompat team wanted to experiment with this.
Differential Revision: https://phabricator.services.mozilla.com/D49792
--HG--
extra : moz-landing-system : lando
The change to await snapshotWindow is something that should have been
done in Bug 1573254.
Differential Revision: https://phabricator.services.mozilla.com/D47510
--HG--
extra : moz-landing-system : lando
This helper function awaits the new custom event sent by the RDM pane
frame script when zooming is done, then waits for the reflow to be
complete also. After this is done, resolution and window and content
sizes all have their correct, final values.
Differential Revision: https://phabricator.services.mozilla.com/D47366
--HG--
extra : moz-landing-system : lando
The ZoomChild actor normally caches its full zoom level only when it is
changed, then emits a FullZoomChange event. That event causes problems
with Responsive Design Mode, which receives the event after other
similar events that carry the full zoom level of the RDM pane content.
The RDM UI pane itself always stays at 1.0 zoom. This change makes the
ZoomChild cache its initial fullZoom level as soon as possible, which
prevents the first RDM zoom change from sending the unwanted event.
Differential Revision: https://phabricator.services.mozilla.com/D49793
--HG--
extra : moz-landing-system : lando
This change makes the RDM content frame script listen to the new
PreFullZoomChange event, and treat that as a trigger to save the
existing resolution. The content window will send 2 resize events
as it adjusts to the new RDM pane size set by the front end. After
these events are received, the resolution is restored and a new
event is fired that indicates the work of zooming is complete.
Differential Revision: https://phabricator.services.mozilla.com/D48624
--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