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
A function is added on the walker actor that creates a NodeFront
from a ContentDomReference, e.g. an object containing a browsingContextId
and a unique DOM element identifier.
A trait is added on the walker actor since the ContentDomReference API was
only added in Firefox 69.
We then add a function on the toolbox that can return a NodeFront from a
element grip.
Differential Revision: https://phabricator.services.mozilla.com/D48808
--HG--
extra : moz-landing-system : lando
This will allow us to retrieve the appropriate inspector
(and thus walker, highlighter, ...) for a given element
later, potentially from a different DebuggerServer.
Differential Revision: https://phabricator.services.mozilla.com/D48807
--HG--
extra : moz-landing-system : lando
The function was close to hit the complexity limit set by eslint,
so we break it up into smaller functions.
We also group assignments where we can.
Differential Revision: https://phabricator.services.mozilla.com/D48806
--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
The webconsole actor now has an associated front for some
time, but the naming of variables and properties didn't
reflect that (most weren't updated and were still calling
it a client).
This patch tries to rename all those variables so it's more
obvious we're dealing with an actual front.
Differential Revision: https://phabricator.services.mozilla.com/D49401
--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
I thought I would contribute to this test.
As it doesn't involve any child actor, I'm not, but this cleanup is still valuable.
Differential Revision: https://phabricator.services.mozilla.com/D49260
--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
**Update October 8**
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 and Patrick for the overall highlighter behavior.
---
This patch adds a base class for the renderer part of highlighters which is set up on the parent process in the browser window.
This is used by the `BoxModelHighlighterRender` introduced by D47092
`HighlighterRenderer.init()` will create an HTML iframe and inject it to the appropriate position in the browser window in order to serve as a rendering surface for highlighters of the inspected page content (content toolbox) or the browser UI (browser toolbox). A host iframe is used until [Bug 1492582](https://bugzilla.mozilla.org/show_bug.cgi?id=1492582) is fixed because the browser window is XUL and does not support the anonymous canvas frame used by existing highlighters.
The primary use case of `HighlighterRenderer` is as a base class for renderers which live in a separate process than the observers. This happens with highlighters for the content toolbox. Therefore, it provides methods to setup a communication system (via MessageManager for now) whereby the observer can send messages to the renderer and vice-versa: `setMessageManager()`, `postMessage()` and `onMessage()`.
I used the existing code from [`AccessibilityParent`](https://searchfox.org/mozilla-central/source/devtools/server/actors/accessibility/accessibility-parent.js) as a reference for this.
Classes that extend HighlighterRenderer must implement:
- a typeName representing the highlighter type; used to differentiate between other types of messages when the Message Manager is used;
- a _buildMarkup() method to generate the highlighter markup;
- a `render()` method to update the highlighter markup when given new information about the observed node.
NOTE: A temporary pink outline is set on the highlighter surface as a quick visual check to show its extent depending on context: browser toolbox or content toolbox. This will be removed before landing.
Differential Revision: https://phabricator.services.mozilla.com/D47091
--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
**Update October 8**
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 and Patrick for the overall highlighter behavior.
---
This patch adds a base class for the renderer part of highlighters which is set up on the parent process in the browser window.
This is used by the `BoxModelHighlighterRender` introduced by D47092
`HighlighterRenderer.init()` will create an HTML iframe and inject it to the appropriate position in the browser window in order to serve as a rendering surface for highlighters of the inspected page content (content toolbox) or the browser UI (browser toolbox). A host iframe is used until [Bug 1492582](https://bugzilla.mozilla.org/show_bug.cgi?id=1492582) is fixed because the browser window is XUL and does not support the anonymous canvas frame used by existing highlighters.
The primary use case of `HighlighterRenderer` is as a base class for renderers which live in a separate process than the observers. This happens with highlighters for the content toolbox. Therefore, it provides methods to setup a communication system (via MessageManager for now) whereby the observer can send messages to the renderer and vice-versa: `setMessageManager()`, `postMessage()` and `onMessage()`.
I used the existing code from [`AccessibilityParent`](https://searchfox.org/mozilla-central/source/devtools/server/actors/accessibility/accessibility-parent.js) as a reference for this.
Classes that extend HighlighterRenderer must implement:
- a typeName representing the highlighter type; used to differentiate between other types of messages when the Message Manager is used;
- a _buildMarkup() method to generate the highlighter markup;
- a `render()` method to update the highlighter markup when given new information about the observed node.
NOTE: A temporary pink outline is set on the highlighter surface as a quick visual check to show its extent depending on context: browser toolbox or content toolbox. This will be removed before landing.
Differential Revision: https://phabricator.services.mozilla.com/D47091
--HG--
extra : moz-landing-system : lando
With fission, we most likely have a process switch and the existing worker
target isn't properly detached. We should ensure releasing the SW whenever
the connection to the server drops
Differential Revision: https://phabricator.services.mozilla.com/D48061
--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
The popup's shortcuts use a different codepath than the popup's buttons.
When using the buttons, the profile was not being captured as a gzipped
profile, and it was using the DevTools' mechanism for getting the symbol
tables. This patch makes the getSymbolTables mechanism configuring in the
recording panel's client.
In addition, browser code made its way into the client. This patch moves
the browser code to all be in browser.js to match the original code
organization for the panel, which was trying to keep browser APIs
out of the React components and Redux store.
Differential Revision: https://phabricator.services.mozilla.com/D45529
--HG--
extra : source : 5a3661caf52faaf67b10fcef9e3121d639a17cc3
The popup's shortcuts use a different codepath than the popup's buttons.
When using the buttons, the profile was not being captured as a gzipped
profile, and it was using the DevTools' mechanism for getting the symbol
tables. This patch makes the getSymbolTables mechanism configuring in the
recording panel's client.
In addition, browser code made its way into the client. This patch moves
the browser code to all be in browser.js to match the original code
organization for the panel, which was trying to keep browser APIs
out of the React components and Redux store.
Differential Revision: https://phabricator.services.mozilla.com/D45529
--HG--
extra : moz-landing-system : lando
When multiple DebuggerClients starts debugging the same content process target,
the first one to close will destroy the other one as we destroy the server
and the loader as soon as we receive the debug:content-process-destroy message.
We should destroy them only once the last client closes.
i.e. when the last connection registered in the content process is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D47661
--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 D47051.
Without the trait, we keep calling the connect() wrapper on the actor, which is supposed to be deprecated
Differential Revision: https://phabricator.services.mozilla.com/D47053
--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
Previously, when creating a new WebConsoleActor, we were
also creating a new Debugger instance.
The problem was that we would never call `enable` on it,
which is what allows to create debuggee for all existing
globals, and for the ones that will be created after.
This means that we had multiple workaround to get a
global debuggee, and in the case of function, would add
a global as a debuggee only to get its script location.
This patch remove the creation of the new Debugger,
and retrieve the parent actor Debugger instance instead.
This shuffles things around a bit, are the Debugger instance
was created by the ThreadActor, but is now by the target
actor (BrowsingContext, ContentProcess, ...).
We can then remove the now unused `getGlobalDebugObject`
hooks we were using in the Function previewer, as we
get a proper Debugger object, with the script location.
Differential Revision: https://phabricator.services.mozilla.com/D44480
--HG--
extra : moz-landing-system : lando
Julian Descottes
jaril
Nicolas Chevobbe
Ehsan Akhgari
Gabriel Luong
Gurzau Raul
Alexandre Poirot
Daisuke Akatsuka
Micah Tigley
Jean-Yves Avenard
Jason Laster
Bogdan Tara
David Walsh
Miriam
Logan Smyth
zhaogang
Cosmin Sabou
Emilio Cobos Álvarez
Michael Ratcliffe
Razvan Caliman
Brian Hackett
Daniel Varga
Johann Hofmann
Patrick Brosset
Boris Chiou
wartmanm
Dorel Luca
Greg Tatum
yulia
Tom Ritter
Pranshu Chittora
Anny Gakhokidze
Sorin Davidoi
Sean Feng
arthur.iakab
Noemi Erli
Paul Zuehlcke
biboswan
Oana Pop Rus
Brian Birtles
Mats Palmgren
Mark Banner
Mihai Alexandru Michis
Jan Odvarko
Ciure Andrei
Brad Werth
Yura Zenevich
championshuttler
Razvan Maries