The format of the Fenix versionName on Nightly no longer matches our regular expression.
Updating the regular expression to accommodate both versions such as "2.1.0" and "Nightly 191016 06:01"
Differential Revision: https://phabricator.services.mozilla.com/D49428
--HG--
extra : moz-landing-system : lando
- Converted the ObjectClient into an protocoljs Front
- Converted the SymbolIteratorClient into a protocoljs Front and moved it to devtools/shared/fronts
- Converted the PropertyIteratorClient into a protocoljs Front and moved it to devtools/shared/fronts
- Converted the EnvironmentClient into a protocoljs Front and moved it to devtools/shared/fronts
- Modified calls to `DebuggerClient.release()` so that it tries to call the ObjectFront's release method first, and falls back on `DebuggerClient.release()` if there's no object front
- Changed reps so that it instantiates only one ObjectClient per grip
- Changed tests so that they expect what the Front's request method resolves to where applicable (i.e. ObjectFront.allocationStack resolves to allocationStack, not a packet object with an allocationStack property)
- Changed callbacks provided to ObjectClient methods to be chained to the ObjectFront methods (e.g. ObjectClient.getScope(callback) changed to ObjectFront.getScope().callback())
- Changed tests to use async/await (test_framebindings-x.js, test_functiongrips-x.js, test_objectgrips-x.js)
- Changed tests to expect protocoljs to throw an error string instead of an error object (test_objectgrips-fn-apply-03.js, test_threadlifetime-02.js, test_pauselifetime-03.js)
Differential Revision: https://phabricator.services.mozilla.com/D48182
--HG--
rename : devtools/shared/client/environment-client.js => devtools/shared/fronts/environment.js
rename : devtools/shared/client/property-iterator-client.js => devtools/shared/fronts/property-iterator.js
rename : devtools/shared/client/symbol-iterator-client.js => devtools/shared/fronts/symbol-iterator.js
extra : moz-landing-system : lando
You can listen for fronts creation via `parentFront.onFront(typeName, callback)`.
For now, we were calling `callback` before we pass the `form` to Front.
This leads to empty attributes as the Front doesn't have access to any data.
Differential Revision: https://phabricator.services.mozilla.com/D49261
--HG--
extra : moz-landing-system : lando
Move analyzeInputString function below JSPropertyProvider, so
the exported function appears first in the file.
Differential Revision: https://phabricator.services.mozilla.com/D49107
--HG--
extra : moz-landing-system : lando
We always have a debugee for the eval window, so we can
remove the now unnecessary check.
We also take this as an opportunity to always attach the
thread when attaching the console in devtools/shared/webconsole/test/common.js
as it's what makes the evalWindow a debuggee.
Differential Revision: https://phabricator.services.mozilla.com/D49105
--HG--
extra : moz-landing-system : lando
Depends on D47092
Given that the highlighter rendering surface is sized to the viewport of the inspected page (as opposed to the whole document), we need a way to ignore scroll offsets when getting data about the node position so the highlighter doesn't get drawn off-screen.
Differential Revision: https://phabricator.services.mozilla.com/D47094
--HG--
extra : moz-landing-system : lando
NOTE: To use the new box model highlighter, flip this pref to true: `devtools.inspector.use-new-box-model-highlighter`
Adding Julian as reviewer to check the sanity of the communication system (see `BoxModelHiglighterObserver` constructor and `BoxModelHighlighterRenderer.setMessageManager()`, `BoxModelHighlighterRenderer.onMessage()`, `BoxModelHighlighterRenderer.postMessage()`) and Patrick for the overall highlighter behavior which is mostly a clean split of the existing [`BoxModelHighlighter`](https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/devtools/server/actors/highlighters/box-model.js)).
---
Depends on D47091
## Preamble
This patch looks more frightening than it actually is. Let me explain:
The vast majority of the code in `box-model-highlighter-observer.js` and `box-model-highlighter-renderer.js` is a clean split of the code existing in `box-model-highlighter.js` into distinct parts which handle the node measurement (observer) and the drawing the highlighter (renderer). I kept the method names identical to help in matching them up with their original sources.
There was no simple way chunk this without confusing the daylight out of you so I decided to co-locate all changes so it's easier to track and reference methods.
I will detail below the important differences.
## Overview:
The box model highlighter is split into two distinct parts:
- an observer which monitors the node's position
- a renderer which draws the highlighter on top of the node
The renderer always lives in the parent process (browser window) and overlays an iframe with the highlighter markup:
- either over the content if highlighting in the context of the content toolbox
- or over the whole browser UI if highlighting in the context of the browser toolbox
When in the context of the browser toolbox (i.e. highlighting the browser UI), both observer and renderer live in the parent process. Communication is done by direct calls.
When in the context of the content toolbox (i.e. highlighting the page content), the observer lives in content process (so it can measure the node) while the renderer lives in the parent process. Communication is done by message passing via `MessageManager` (soon to be deprecated and replaced with JSWindowActor API)
## Notable differences after the split
- the observer checks whether it is in the content process (aka child process) and sets up the highlighter in the parent process by using [`setupInParent()`](https://docs.firefox-dev.tools/backend/actor-e10s-handling.html) and establishes a communication system to it via message manager. If the observer is in the parent process (browser toolbox scenario), the renderer is setup directly via its constructor and no additional communication system is required.
- whenever the node quads change (as determined by the untouched existing base class `auto-refresh.js`), the observer gathers the data about the node position and sends it over to the renderer. This happens in the `BoxModelHighlighterObserver._update()` (corresponding to the [`_update()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#361-383)).
- the renderer expects its `render()` method to be called with the necessary node position information whenever it should update the highlighter. It is the entry point which then calls all the DOM manipulation methods copied over from the existing box model highlighter.
- the only notable change in DOM manipulation methods is in `BoxModelHighlighterRenderer._updateBoxModel()` (corresponding to [`updateBoxModel()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#504-560)) where the `_nodeNeedsHighlighting()` is kept on the observer part and the canvas zoom adjustment is removed (`this.markup.scaleRootElement(this.currentNode, rootId)`) because the canvas is no longer influenced by the page zoom (the canvas lives in the browser window, not the content window)
Differential Revision: https://phabricator.services.mozilla.com/D47092
--HG--
rename : devtools/server/actors/highlighters/box-model.js => devtools/server/actors/highlighters/box-model-renderer.js
extra : moz-landing-system : lando
Depends on D47092
Given that the highlighter rendering surface is sized to the viewport of the inspected page (as opposed to the whole document), we need a way to ignore scroll offsets when getting data about the node position so the highlighter doesn't get drawn off-screen.
Differential Revision: https://phabricator.services.mozilla.com/D47094
--HG--
extra : moz-landing-system : lando
NOTE: To use the new box model highlighter, flip this pref to true: `devtools.inspector.use-new-box-model-highlighter`
Adding Julian as reviewer to check the sanity of the communication system (see `BoxModelHiglighterObserver` constructor and `BoxModelHighlighterRenderer.setMessageManager()`, `BoxModelHighlighterRenderer.onMessage()`, `BoxModelHighlighterRenderer.postMessage()`) and Patrick for the overall highlighter behavior which is mostly a clean split of the existing [`BoxModelHighlighter`](https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/devtools/server/actors/highlighters/box-model.js)).
---
Depends on D47091
## Preamble
This patch looks more frightening than it actually is. Let me explain:
The vast majority of the code in `box-model-highlighter-observer.js` and `box-model-highlighter-renderer.js` is a clean split of the code existing in `box-model-highlighter.js` into distinct parts which handle the node measurement (observer) and the drawing the highlighter (renderer). I kept the method names identical to help in matching them up with their original sources.
There was no simple way chunk this without confusing the daylight out of you so I decided to co-locate all changes so it's easier to track and reference methods.
I will detail below the important differences.
## Overview:
The box model highlighter is split into two distinct parts:
- an observer which monitors the node's position
- a renderer which draws the highlighter on top of the node
The renderer always lives in the parent process (browser window) and overlays an iframe with the highlighter markup:
- either over the content if highlighting in the context of the content toolbox
- or over the whole browser UI if highlighting in the context of the browser toolbox
When in the context of the browser toolbox (i.e. highlighting the browser UI), both observer and renderer live in the parent process. Communication is done by direct calls.
When in the context of the content toolbox (i.e. highlighting the page content), the observer lives in content process (so it can measure the node) while the renderer lives in the parent process. Communication is done by message passing via `MessageManager` (soon to be deprecated and replaced with JSWindowActor API)
## Notable differences after the split
- the observer checks whether it is in the content process (aka child process) and sets up the highlighter in the parent process by using [`setupInParent()`](https://docs.firefox-dev.tools/backend/actor-e10s-handling.html) and establishes a communication system to it via message manager. If the observer is in the parent process (browser toolbox scenario), the renderer is setup directly via its constructor and no additional communication system is required.
- whenever the node quads change (as determined by the untouched existing base class `auto-refresh.js`), the observer gathers the data about the node position and sends it over to the renderer. This happens in the `BoxModelHighlighterObserver._update()` (corresponding to the [`_update()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#361-383)).
- the renderer expects its `render()` method to be called with the necessary node position information whenever it should update the highlighter. It is the entry point which then calls all the DOM manipulation methods copied over from the existing box model highlighter.
- the only notable change in DOM manipulation methods is in `BoxModelHighlighterRenderer._updateBoxModel()` (corresponding to [`updateBoxModel()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#504-560)) where the `_nodeNeedsHighlighting()` is kept on the observer part and the canvas zoom adjustment is removed (`this.markup.scaleRootElement(this.currentNode, rootId)`) because the canvas is no longer influenced by the page zoom (the canvas lives in the browser window, not the content window)
Differential Revision: https://phabricator.services.mozilla.com/D47092
--HG--
rename : devtools/server/actors/highlighters/box-model.js => devtools/server/actors/highlighters/box-model-renderer.js
extra : moz-landing-system : lando
Protocol.js's Front and Pool's destroy are not expected to be async.
But TargetMixin.destroy is. It makes DebuggerClient.close do not wait
for all Target fronts destroys correctly. The client close method calls
the cleanup method of all the pools. Top level fronts are pools.
Target fronts are still self managed and so are pools.
And so, when we close the toolbox, the target destroy is still pending
after toolbox.destroy is resolved.
Differential Revision: https://phabricator.services.mozilla.com/D46221
--HG--
extra : moz-landing-system : lando
This will later allow dynamically change this value for local tabs,
during Fission processes switches.
Differential Revision: https://phabricator.services.mozilla.com/D48070
--HG--
extra : moz-landing-system : lando
The original plan for the node-picker to work with multiple targets was introduced in D41598 (in bug 1568825). The idea was that, because we can have multiple independent inspectable targets, and because the client is the one doing the orchestration between them, to let the client start the node picker in all targets at once.
At the time of this first change, the code was create with this in mind, but there was really just one target (the top-level one).
So, this revision introduces the real code for this. First of all, I removed the now obsolete `getAllInspectorFronts` in `node-picker.js` because we now have a similar function on the inspector front directly.
Then the main code changes to look for are on the actor side, in the `HighlighterActor`. This is where the picking actually happens.
You have to remember that several targets will be picking at the same time, and therefore several `HighlighterActor` instances will be in pick mode at the same time.
The way they allow users to pick is by listening to mouse events (mousemove and clicks essentially).
Because these actors can't see or talk to each other, one can't tell the others that the mouse is now over its content and the other pickers should pause somewhat.
So, when one of them sees that the mouse event is happening on a remote frame, then it bails out and lets events through without handling them. This is so that the embedded document (which also has a picker running) can get a chance to receive the mouse events too.
The other aspect is that each `HighlighterActor`, when picking, does its own highlighting. So if there are 3 remote frames, then there really are 3 highlighters.
So the trick is to make sure only one of them ever appears at any given time. Again, these actors can't talk to each other directly, so the client is responsible for doing this when receiving events that a node was hovered.
This is not perfect, but should normally get far better when the new fission-compatible highlighter is in place. Indeed, when that happens, we won't have to care about this anymore, there will be only one `HighlighterRenderer` for the entire tab. So even if there are multiple `HighlighterActor` instances picking, they will all be sending events to the same renderer.
The only exception is in the browser toolbox where you can inspect both the browser UI and the content UI. In this case, there will be 2 renderers: one over the entire browser window, and one over the <browser> area. So we'll still have to do the dance of hiding one when the other is shown.
Differential Revision: https://phabricator.services.mozilla.com/D42640
--HG--
extra : moz-landing-system : lando
When debugging firefox instance, we open about:devtools toolboxes,
without any remoteId attribute. So that we create a brand new DebuggerClient
instance. For now, this instance is only ever closed if the debugged target
is a local tab. We should try to close the clients for all cases.
Remote debugging clients are ignored and I think are still left opened.
Differential Revision: https://phabricator.services.mozilla.com/D47112
--HG--
extra : moz-landing-system : lando
We weren't using the shared defer function because
at some point it was still using Promise.jsm,
which is slow.
But since Bug 1388054, it's not using Promise.jsm anymore,
so we can use the shared function.
We take this as an opportunity to clean up
the shared defer file comments.
Differential Revision: https://phabricator.services.mozilla.com/D47739
--HG--
extra : moz-landing-system : lando
Adds another method on the Emulation actor that screenshots the page content. Here, another instance of the ScreenshotActor is managed by the Emulation actor. The ScreenshotActor already provides methods to handle capturing page content along with additional options such as screenshotting the full page, which we may want to use in the future.
Differential Revision: https://phabricator.services.mozilla.com/D46092
--HG--
extra : moz-landing-system : lando
Depends on D46957
We are updating three call sites that were still relying on window.top to get the topmost window.
For `getFrameOffsets` and `getRect`, they are currently only called with a non-null `boundaryWindow` argument.
That's why this didn't trigger any regression.
For `getFrameElement`, I could only find STRs that don't have any user impact.
For instance, when the BrowserToolbox debugs a page where you open DevTools, this will load the toolbox in an iframe.
This load will trigger `onFrameLoad` in the walker actor. And because we were using `win.top`, getFrameElement would return null, and onFrameLoad will not emit mutations.
But I couldn't see any scenario where this had an actual impact for users.
Differential Revision: https://phabricator.services.mozilla.com/D46958
--HG--
extra : moz-landing-system : lando
Depends on D47050. Trait was added in 2017, all servers should now have support this by default
Differential Revision: https://phabricator.services.mozilla.com/D47051
--HG--
extra : moz-landing-system : lando
Also, update the serialization by the shorter perference because this is
a new feature and using older syntax doesn't make sense.
Besides, use `cssOffset` for web animation IDL attribute name.
Differential Revision: https://phabricator.services.mozilla.com/D45607
--HG--
extra : moz-landing-system : lando
shared-head.js is loaded by the suite's head.js file. telemetry-helpers is loaded by shared-head itself.
Differential Revision: https://phabricator.services.mozilla.com/D46475
--HG--
extra : moz-landing-system : lando
The flexbox inspector is different from the grid inspector in that it
does not list all of the flexbox layouts on the page. In D45524 we needed
to list all of the LayoutFronts to retrieve all of the GridFronts in the
page. However here, we do not need to do this. We only need to get the
LayoutFront contextual to the NodeFront currently selected.
I also took this opportunity to remove an old backward-compatibility
check called hasGetCurrentFlexbox which was no longer required since it
guarded a feature added in Fx60.
Differential Revision: https://phabricator.services.mozilla.com/D46299
--HG--
extra : moz-landing-system : lando
