The highlighters weren't working in remote frame as the StyleSheetEditor
was always trying to use the top-level walker and highlighter fronts.
To fix that, we retrieve the appropriate fronts given the stylesheet
resource.
The existing test is augmented, which meant making the highlighterTestActor
slightly better.
Differential Revision: https://phabricator.services.mozilla.com/D128354
The following test suites are green in https-first with this patch:
devtools/client/memory/test/browser/browser.ini
devtools/client/responsive/test/browser/browser.ini
devtools/client/shared/test/browser.ini
devtools/client/styleeditor/test/browser.ini
devtools/shared/commands/resource/tests/browser.ini
Differential Revision: https://phabricator.services.mozilla.com/D128082
All these tests most likely have been fixed with the enabling of server targets.
Because bfcache in parent was introducing more cross process navigations,
being initiated from the server, having the support of server targets was uterly
important to support bfcacheInParent.
Differential Revision: https://phabricator.services.mozilla.com/D123448
We used to handle navigation with a subtle and complex combination of target-available + dom-loading.
Just because we were missing will-navigate event in some cases.
But will-navigate is now reliable and is fired in all types of navigations.
Differential Revision: https://phabricator.services.mozilla.com/D120961
Renaming the actor makes it more explicit that it should
only be used for highlighter-related assertions.
We take this opportunity to rename all the 'testActor' instances
in tests to 'highlighterTestFront' which better represents
what the object is.
While doing this work, I was able to cleanup a few function definition
where the testActor parameter wasn't needed.
Differential Revision: https://phabricator.services.mozilla.com/D117978
Depends on D110368
Both the flag and the event are not used.
The only thing which matters from the framework perspective is to wait for panel.open to resolve.
Differential Revision: https://phabricator.services.mozilla.com/D110369
With the previous patches in this queue, it looks like the
timing is stlightly modified, and on initial load we can
reveive stylesheet resources _before_ the intial dom-loading
event.
Since we're using dom-loading to clear the UI, we might destroy
stylesheets that we shouldn't.
We fix that in 2 folds:
- clear the UI in onTargetAvailable, which we do receive before any resources
- add a flag to the `dom-loading` resource when we're already going to be triggering
onTargetAvailable for a given interaction (toolbox opening, cross-process
navigation or any navigation when target will follow the global lifecycle).
Differential Revision: https://phabricator.services.mozilla.com/D109471
With the previous patches in this queue, it looks like the
timing is stlightly modified, and on initial load we can
reveive stylesheet resources _before_ the intial dom-loading
event.
Since we're using dom-loading to clear the UI, we might destroy
stylesheets that we shouldn't.
We fix that in 2 folds:
- clear the UI in onTargetAvailable, which we do receive before any resources
- add a flag to the `dom-loading` resource when we're already going to be triggering
onTargetAvailable for a given interaction (toolbox opening, cross-process
navigation or any navigation when target will follow the global lifecycle).
Differential Revision: https://phabricator.services.mozilla.com/D109471
I kept a few having some overrides. But they may be irrelevant.
And I kept some eslint files for all folder that aren't matching the pattern matching "**/test*/**/browser*/".
Ideally we would rename these folder to match.
Last but not least, I identified one case where we were using mochitest file for xpcshell tests!
Differential Revision: https://phabricator.services.mozilla.com/D109481
Depends on D105999
This patch is mostly a mechanical rewrite of:
```lang=javascript
const target = await TargetFactory.forTab(tab);
const toolbox = await gDevTools.showToolbox(target, "inspector");
```
to
```lang=javascript
const toolbox = await gDevTools.showToolboxForTab(tab, { toolId: "inspector" });
```
The main changes are:
- if the target was actually used in the test, it is now retrieved from toolbox.target
- the arguments for showToolboxForTab are using an option argument, to avoid the occasional showToolbox("inspector", null, null, null, startTime, null, reason);
I suspect that any signature rewrite mistake would have been caught on try.
There a few less mechanical changes:
- devtools/client/framework/test/browser_toolbox_screenshot_tool.js the toolId "console" was omitted because this id doesn't match any tool (author probably meant "webconsole")
- a few tests were: 1/ first creating a target, 2/ looping on tool definitions to get supported tools 3/ opening the toolbox with each supported tool. To support this I extracted a helper called `getSupportedToolIds` which opens a temporary toolbox to list all supported tool ids
- all the tests under storage/ use a single helper to start the test, which can open toolboxes for both tab targets and other targets. This made it more complicated to refactor. We could also drop this part and just refactor each test when we actually modify forTab/showToolbox to only work with descriptors
All in all the goal of this stack is to pave the way to stop handling targets when using forTab/showToolbox, and behind the scenes stop replying on targets to cache open toolboxes. We don't aim to kill all the call sites, just get them to a smaller number so that the next refactors will be easier.
Differential Revision: https://phabricator.services.mozilla.com/D106000
Depends on D105999
This patch is mostly a mechanical rewrite of:
```lang=javascript
const target = await TargetFactory.forTab(tab);
const toolbox = await gDevTools.showToolbox(target, "inspector");
```
to
```lang=javascript
const toolbox = await gDevTools.showToolboxForTab(tab, { toolId: "inspector" });
```
The main changes are:
- if the target was actually used in the test, it is now retrieved from toolbox.target
- the arguments for showToolboxForTab are using an option argument, to avoid the occasional showToolbox("inspector", null, null, null, startTime, null, reason);
I suspect that any signature rewrite mistake would have been caught on try.
There a few less mechanical changes:
- devtools/client/framework/test/browser_toolbox_screenshot_tool.js the toolId "console" was omitted because this id doesn't match any tool (author probably meant "webconsole")
- a few tests were: 1/ first creating a target, 2/ looping on tool definitions to get supported tools 3/ opening the toolbox with each supported tool. To support this I extracted a helper called `getSupportedToolIds` which opens a temporary toolbox to list all supported tool ids
- all the tests under storage/ use a single helper to start the test, which can open toolboxes for both tab targets and other targets. This made it more complicated to refactor. We could also drop this part and just refactor each test when we actually modify forTab/showToolbox to only work with descriptors
All in all the goal of this stack is to pave the way to stop handling targets when using forTab/showToolbox, and behind the scenes stop replying on targets to cache open toolboxes. We don't aim to kill all the call sites, just get them to a smaller number so that the next refactors will be easier.
Differential Revision: https://phabricator.services.mozilla.com/D106000
There is still some usages in isTargetSupported,
but that would requires refactoring this method into isDescriptorSupported
and be async as some isTargetSupported only works against target as it checks for traits on it.
Differential Revision: https://phabricator.services.mozilla.com/D105201
When the user edits a stylesheet in the StyleEditor, an `_isUpdating` flag is toggled,
and a request is sent to the server to actually apply those changes to the stylesheet.
It then causes a style-applied event to be emitted (or the stylesheet resource
to be updated, if watcher support is enabled for stylesheet).
In the end, this triggers the onStyleApplied function in the StyleEditor, where
we check if the `_isUpdating` flag is true (to know if the event was caused
through editing in style editor), and if not, replace the stylesheet content.
Unfortunately there's a race condition when the user is typing (and sending
multiple requests to the server), as the state of the _isUpdating flag could
be wrong if a new request is sent before the first one is handled.
This is probably highlighted with the throttling we're doing in the Resource API.
To fix this issue, we add a new `cause` parameter to the StyleSheets.update method,
which we set to `styleeditor` when calling update within the StyleEditor.
This `cause` parameter is then sent back by the server to the client (via the
style-applied event, or the resource update if we have Watcher support for stylesheets).
This `cause` can be checked by the StyleEditor client, and replace the check
on `_isUpdating`.
However, we need to keep the `_isUpdating` property to handle backward compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D99862
This turns all existing backward compatibility comments (or
comments mentioning a specific Firefox version), into the new
syntax we agreed upon in Bug 1673535.
Differential Revision: https://phabricator.services.mozilla.com/D97395
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
The previous code, emitting the event from Toolbox.onTargetAvailable,
wasn't waiting for the call to TargetList.startListening which is done
from TargetList.onTargetAvailable.
Differential Revision: https://phabricator.services.mozilla.com/D82664
Since targetFronts now have isTopLevel and targetType properties, we can directly use
those, as the targetFront is included in the callback parameter.
This patch remove those properties and refactor consumer code.
Differential Revision: https://phabricator.services.mozilla.com/D74651
Since targetFronts now have isTopLevel and targetType properties, we can directly use
those, as the targetFront is included in the callback parameter.
This patch remove those properties and refactor consumer code.
Differential Revision: https://phabricator.services.mozilla.com/D74651
