Importing scripts in shared head files is hard to maintain because it forces all browser ini that use the shared file to whitelist all its imports.
The debugger context helper is almost unused in the inspector, so it would be easier to just import it in the few tests that require it.
Also removed the whitelist entry in rules' browser.ini, no test in this suite used it.
Differential Revision: https://phabricator.services.mozilla.com/D30882
--HG--
extra : moz-landing-system : lando
### Changes
Probably the most important change apart from the tooltips is that we now only support one property at a time. This allows us to short circuit at the first invalid property and improve performance. This was previously agreed with Razvan but there were some relics left in the code.
`toolbox.xul`
- Added tooltips.ftl
`devtools/client/inspector/markup/test/helper_events_test_runner.js`:
- Had to change to synthesizeMouseAtCenter because CSS changes caused the original to fail.
`devtools/client/inspector/rules/rules.js`:
- Added `VIEW_NODE_INACTIVE_CSS` to node types and sorted alphabetically.
- Added new nodeInfo data for Inactive CSS icons.
`devtools/client/inspector/rules/test/browser_rules_inactive_css_flexbox.js` &
`devtools/client/inspector/rules/test/browser_rules_inactive_css_grid.js`:
- removed some listeners that are no longer needed
`devtools/client/inspector/rules/test/head.js`:
- Refactored `getPropertiesForRuleIndex()` in order to pass along information needed for testing our Fluent strings.
- Refactored `checkDeclarationIsInactive()` to check tooltip contnts using a new method.
- Added `checkInteractiveTooltip()` for checking the tooltip contents themselves.
- Simple changes to `runInactiveCSSTests()`.
`devtools/client/inspector/rules/views/text-property-editor.js`:
- We no longer create the tooltip by adding the title attribute.
`devtools/client/inspector/shared/node-types.js`:
- Changed the enum to use strings to simplify debugging.
- Added `VIEW_NODE_INACTIVE_CSS`.
- Sorted alphabetically.
`devtools/client/inspector/shared/tooltips-overlay.js`:
- Introduced a new tooltip type called `interactiveTooltip`.
`devtools/client/locales/en-US/inspector.properties`:
- Removed strings.
`devtools/client/locales/en-US/tooltips.ftl`:
- Added structured versions of the properties from `inspector.properties`.
`devtools/client/shared/widgets/tooltip/HTMLTooltip.js`:
- Made the tooltips obey the "prevent popup autohide" option in the browser debugger.
`devtools/client/shared/widgets/tooltip/InactiveCSSTooltipHelper.js`:
- Main file for handling InactiveCSS Tooltips.
`devtools/client/themes/tooltips.css`:
- Made arrow tooltips follow the Proton theme.
`devtools/server/actors/utils/inactive-property-helper.js`:
- General changes to support Fluent.
- Bail on first inactive property found.
### Latest Try (expecting green)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=de28939206d444dc4b534a3e5cc7a84b8797bec3
Differential Revision: https://phabricator.services.mozilla.com/D29372
--HG--
extra : moz-landing-system : lando
### Summary of Changes
1. Added `element-style.js::refreshUnusedCssAll()`:
- This method refreshes the CSS declarations for every property change and then calls `element-style.js::_updatePropertyUsed()` for each pseudo element.
2. Added `element-style.js::_updatePropertyUsed()`:
- This method simply updates the unused CSS HTML for each property that needs it.
3. Added `alerticon-unused.svg`.
4. A tiny bit of tidying in `devtools/client/themes/rules.css`:
- Added blank lines before comments.
- Changed `0px` to `0`;
- Merged both the `#ruleview-class-panel .classes` rules.
- Added used and unused CSS styles.
- Hooked `InactivePropertyHelper` into `devtools/server/actors/styles.js`
5. `devtools/server/actors/utils/inactive-property-helper.js` contains the actual unused CSS engine.
6. This feature exposed a race condition inside `head.js::assertShowPreviewTooltip()`. It was mousing over an element and sometimes the tooltip emitted "shown" before we added the listener. This is now fixed.
### Try
https://treeherder.mozilla.org/#/jobs?repo=try&revision=016f8dc8e05dbaa89bc5a79b822ce23e786d3fc1
Differential Revision: https://phabricator.services.mozilla.com/D26879
--HG--
extra : moz-landing-system : lando
With the changes I made, any time the debugger is paused, only the token directly after the column breakpoint is highlighted. My commit also changes highlighting rules for debug lines without column breakpoints. I collected examples in the document below demonstrating cases with and without column breakpoints.
https://docs.google.com/document/d/1w9kaAzVgns5oQnONTPuPiREyhaq6NGd4mp6yvVUEU1Y/edit?usp=sharing
I changed one CSS file because without that change, the next column breakpoint after the token would also be highlighted which was misleading.
I would appreciate any feedback on these changes. Thank you!
Differential Revision: https://phabricator.services.mozilla.com/D30089
--HG--
extra : moz-landing-system : lando
Simply moved the callback from the icon to the button and updated the test.
Differential Revision: https://phabricator.services.mozilla.com/D30339
--HG--
extra : moz-landing-system : lando
Depends on D28036
If a context menu is opened in the toolbox document when running in a frame with type=content, keyboard navigation will not move to the context menu when it's opened.
Differential Revision: https://phabricator.services.mozilla.com/D27695
--HG--
extra : moz-landing-system : lando
Depends on D27693
Menu::popup and popupAtZoom are expecting a toolbox argument as last argument.
However, half of the callsites do not have access to the toolbox and just pass
a { doc } object. This is misleading when trying to work on menu.js because you
cannot rely on toolbox APIs.
Differential Revision: https://phabricator.services.mozilla.com/D28036
--HG--
extra : moz-landing-system : lando
Using chromeEventHandler will allow us to catch events fired from any frame.
By default when DevTools are in a type=chrome frame, events also bubble across frames.
With type=content this is no longer the case.
Differential Revision: https://phabricator.services.mozilla.com/D27693
--HG--
extra : moz-landing-system : lando
The original bug was being caused by a mouseleave from the token and mouseenter into the bracket arrow being triggered immediately after the preview was rendered. This appears less often on longer variable names, but happen all the time for single character variable names.
The problem no longer persists after removing cursor events from the bracket arrow.
Differential Revision: https://phabricator.services.mozilla.com/D30222
--HG--
extra : moz-landing-system : lando
Depends on D28036
If a context menu is opened in the toolbox document when running in a frame with type=content, keyboard navigation will not move to the context menu when it's opened.
Differential Revision: https://phabricator.services.mozilla.com/D27695
--HG--
extra : moz-landing-system : lando
Depends on D27693
Menu::popup and popupAtZoom are expecting a toolbox argument as last argument.
However, half of the callsites do not have access to the toolbox and just pass
a { doc } object. This is misleading when trying to work on menu.js because you
cannot rely on toolbox APIs.
Differential Revision: https://phabricator.services.mozilla.com/D28036
--HG--
extra : moz-landing-system : lando
Using chromeEventHandler will allow us to catch events fired from any frame.
By default when DevTools are in a type=chrome frame, events also bubble across frames.
With type=content this is no longer the case.
Differential Revision: https://phabricator.services.mozilla.com/D27693
--HG--
extra : moz-landing-system : lando
Add an `if` statement to handle logpoint when double click.
Add Mochitest for both conditional breakpoint and logpoint
Differential Revision: https://phabricator.services.mozilla.com/D30291
--HG--
extra : moz-landing-system : lando
Once RDM is up-and-running, the Zoom UI will stay synchronized with the
zoom level of the RDM content pane. These changes ensure that the RDM
tools are forced to 100%, and then does a fixup to get the Zoom UI to
match the RDM content pane zoom level again.
Differential Revision: https://phabricator.services.mozilla.com/D26045
--HG--
extra : moz-landing-system : lando
There is no need to transfer these properties because the swap makes
the outer browser act as if it is remote, and then the message manager
tunnel ensures that the outer browser will get and set the zoom values
from the inner browser.
Differential Revision: https://phabricator.services.mozilla.com/D29911
--HG--
extra : moz-landing-system : lando
The prior code calls '.cleanup()', but ActorPools have no 'cleanup' method. I
think it means to call 'destroy'.
Differential Revision: https://phabricator.services.mozilla.com/D29755
--HG--
extra : moz-landing-system : lando
- Use an explicit 12x12 size in the SVG code
- Add a 12x12 variant of the globe icon, with a 1px stroke similar to the info icon
- Tweak the inner shapes of the info icon so that it looks a bit more clearly like a lowercase "i"
Differential Revision: https://phabricator.services.mozilla.com/D29961
--HG--
extra : moz-landing-system : lando
The conditional breakpoint panel is wrapped in CodeMirror (starting from 6b0b968515). When hitting `Enter`, debugger/node_modules/codemirror/lib/codemirror.js will run line 7153 onKeyDown(), in which a new line is added. Then ConditionalPanel.js onKey() runs.
Solution: Ask CodeMirror not to add a new line when hit `Enter`.
Question:
I added two test cases to Mochitest. If I put a `debugger;` statement in the test file, ran ./mach mochitest --jsdebugger file/path`, keep `step over`, all tests pass. But when I ran`./mach mochitest same/file/path`, terminal stopped at "waiting for state change" then gave an error "Failed to retrieve MOZ_UPLOAD_DIR env var."
Error message screenshot:
{F1285339}
Differential Revision: https://phabricator.services.mozilla.com/D29068
--HG--
extra : moz-landing-system : lando
This mochitest had a very short SW timeout of 1 second, sometimes the worker would already be terminated before we could finish to attach a toolbox.
Increase the timeout to 4 seconds.
Differential Revision: https://phabricator.services.mozilla.com/D29154
--HG--
extra : moz-landing-system : lando
Changes impact theme-twisty icons in the TreeView component:
- Make sure theme-twisty uses the selection color (white) in selected rows;
but override that style for Network details accordion headers.
- Improve the vertical alignment and pixel-perfect icon rendering by
making sure the icon element takes the full available height (16px)
and avoiding assymetrical padding (affects the rendering of centered
background-image, making them blurry on 1x displays).
- Tweak the horizontal spacing of theme-twisty icons so that they take
up a total of 20px width (similar to what is used in Debugger and
Inspector), versus 17px previously.
Differential Revision: https://phabricator.services.mozilla.com/D29550
--HG--
extra : moz-landing-system : lando
This patch introduces a new type of content process, which has a dynamic name.
This type of content process is labeled as `webIsolated=${SITE_ORIGIN}` and is
used within fission-enabled windows.
To enable this, additional information about the fission status of the target
window must be passed into E10SUtils. This was done by updating every call site
manually to pass an extra boolean. A better solution perhaps should be used in
the future.
With this patch enabled, we now perform process switches, but only when
navigating to HTTP URIs. If we navigate to a non-HTTP URI in an iframe with
fission enabled, it will not behave correctly. This must be done in a
follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29570
--HG--
extra : moz-landing-system : lando
Depends on D28457
This commit separates the test-related changes from part one in D28457.
It updates the test fixtures to include the newly introduced `cssSelectors` field for messages used in tests.
It adds a test file for the newly introduced `CSSWarning` React component which is mostly a trimmed-down clone of the test for `PageError` component from which the component was forked. For now, just the basic toggle behavior of the component is tested. The test for calling the server to query DOM elements is not yet instrumented.
Differential Revision: https://phabricator.services.mozilla.com/D29345
--HG--
extra : moz-landing-system : lando
This patch builds on [Bug 1537876](https://bugzilla.mozilla.org/show_bug.cgi?id=1537876) which associates CSS selectors with error messages where applicable.
This patch introduces a new React component, `CSSWarning`, for messages of type CSS. It forks the`PageError` component which was shared for `LOG` messages of type `JAVASCRIPT` and type `CSS`.
The `CSSWarning` component is expandable when the message has an associated CSS selector. When expanded, it runs a `document.querySelectorAll()` command to list all elements matching the selector. Clicking on any of the elements in the result jumps to the Inspector and select the corresponding node in the markup view.
Not all errors have associated CSS selectors. Not all selectors match elements. The errors/warnings are a result of the CSS Parser; there is no guarantee that the CSS rule is used anywhere on the document. The query may return an empty `NodeList`.
Differential Revision: https://phabricator.services.mozilla.com/D28457
--HG--
extra : moz-landing-system : lando
Removed the Service Workers menu item, added Remote Debugging instead. Remote Debugging is displayed just above WebIDE
Differential Revision: https://phabricator.services.mozilla.com/D29219
--HG--
extra : moz-landing-system : lando
Added borders for error / warning messages. Reduced line height in message body. Added more space between device list / message and refresh device button
Differential Revision: https://phabricator.services.mozilla.com/D29652
--HG--
extra : moz-landing-system : lando
Fixed second line that has been cut off in the sidebar item detail of the remote runtime
Differential Revision: https://phabricator.services.mozilla.com/D29649
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
The button (using a div) did not have any hover state before this patch.
While the CSS tried to control the stroke color, the SVG was not set up
for this – also fixed in this bug to correctly use the theme colors.
Differential Revision: https://phabricator.services.mozilla.com/D24742
--HG--
extra : moz-landing-system : lando
Finally! the goal of all of this: removing three functions from threadClient that really belong as part of source client. PauseLongString is never used except in tests. ThreadLongString is only ever used by sourceClient. Same goes for the arrayBuffer method. This clears all of that out.
Differential Revision: https://phabricator.services.mozilla.com/D21715
--HG--
extra : moz-landing-system : lando
This introduces an ArrayBuffer front, so that we no longer need to go through the thread client to get an array buffer for the sourceFront (this is the only place it is used).
It also converts the arrayBufferActor to a protocol.js actor. I was running into an issue between them. I need to double check what this issue was. If these two refactors need to be split, I can do that, but for now it looks like it wasn’t that large of a change.
Differential Revision: https://phabricator.services.mozilla.com/D27878
--HG--
rename : devtools/shared/client/array-buffer-client.js => devtools/shared/fronts/array-buffer.js
extra : moz-landing-system : lando
### Summary of Changes
1. Added `element-style.js::refreshUnusedCssAll()`:
- This method refreshes the CSS declarations for every property change and then calls `element-style.js::_updatePropertyUsed()` for each pseudo element.
2. Added `element-style.js::_updatePropertyUsed()`:
- This method simply updates the unused CSS HTML for each property that needs it.
3. Added `alerticon-unused.svg`.
4. A tiny bit of tidying in `devtools/client/themes/rules.css`:
- Added blank lines before comments.
- Changed `0px` to `0`;
- Merged both the `#ruleview-class-panel .classes` rules.
- Added used and unused CSS styles.
- Hooked `InactivePropertyHelper` into `devtools/server/actors/styles.js`
5. `devtools/server/actors/utils/inactive-property-helper.js` contains the actual unused CSS engine.
6. This feature exposed a race condition inside `head.js::assertShowPreviewTooltip()`. It was mousing over an element and sometimes the tooltip emitted "shown" before we added the listener. This is now fixed.
### Try
https://treeherder.mozilla.org/#/jobs?repo=try&revision=016f8dc8e05dbaa89bc5a79b822ce23e786d3fc1
Differential Revision: https://phabricator.services.mozilla.com/D26879
--HG--
extra : moz-landing-system : lando
After reviewing how the EnvironmentClient is used, it looks like the use of eventSource
might be some cruft from the past. Here is the try run:
https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=242251058&revision=df4bb52f188f79b8006e8c40401e5af2258493ce
with the exception of whatever is going on Window 7 (which appeares also on central), it looks like
things are working as expected. The environment client will eventually have the event emitter, once
it is moved to being a front.
adding @nchevobbe as a subscriber, as this touches a dependancy of the scratchpad.
Differential Revision: https://phabricator.services.mozilla.com/D28962
--HG--
extra : moz-landing-system : lando
Fixes a small issue with the splitconsole shortcut in about:devtools-toolbox
Differential Revision: https://phabricator.services.mozilla.com/D29028
--HG--
extra : moz-landing-system : lando
The idea is to wait for ADB runtimes to be available before trying to render the initial route.
This way if we happen to find the runtime matching the current runtime, and if we still have a connected client for it, we can display the same runtime page.
Differential Revision: https://phabricator.services.mozilla.com/D28094
--HG--
extra : moz-landing-system : lando
The test is marked as perma-fail because there are complications with
getting RDM and WindowSnapshot.js to work together. 4 approaches are
discussed in the test itself, and one is attempted, which perma-fails.
The approach that is attempted is the most likely to be turned into an
unexpected pass in the future, so the test is being added as perma-fail.
Differential Revision: https://phabricator.services.mozilla.com/D28900
--HG--
extra : moz-landing-system : lando
Include the name of the window/parent hostname in the save HAR filename, e.g. if on mozilla.org, would download as "mozilla.org_Archive [time].har"
Differential Revision: https://phabricator.services.mozilla.com/D28732
--HG--
extra : moz-landing-system : lando
Depends on D27686
Toolbox, zoom keys and inspector search should use the chromeeventhandler as event target.
They need to capture events from inner frames.
Differential Revision: https://phabricator.services.mozilla.com/D27688
--HG--
extra : moz-landing-system : lando
As we will move shortcuts to use chromeEventHandler as their target, we need an easy way to add and remove them on host switch.
The chromeEventHandler will change when switching from window to docked hosts (and vice versa)
Differential Revision: https://phabricator.services.mozilla.com/D27685
--HG--
extra : moz-landing-system : lando
Add a max width on infobar when inspecting elements.
The intent is to prevent very long infobars due to autogenerated classes or id.
Differential Revision: https://phabricator.services.mozilla.com/D28276
--HG--
extra : moz-landing-system : lando
Using split("-") was clashing with the connection type "this-firefox".
Added unit test for remote-client-manager.
Differential Revision: https://phabricator.services.mozilla.com/D28066
--HG--
extra : moz-landing-system : lando
Depends on D28629
Follows exactly the same pattern as showSystemAddons. Enabled by default for local builds, disabled otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D28630
--HG--
extra : moz-landing-system : lando
Using the toolbox window to read the "direction" seems to fix the issue.
Added a mochitest, had to create a dedicated browser ini file in order to setup RTL properly.
Differential Revision: https://phabricator.services.mozilla.com/D28841
--HG--
extra : moz-landing-system : lando
The className was making the color purple, although we want it to be red.
Removing the className makes it red.
Differential Revision: https://phabricator.services.mozilla.com/D28616
--HG--
extra : moz-landing-system : lando
Ensure the button to copy all changes remains in view even when the Changes panel is overflowing vertically.
Differential Revision: https://phabricator.services.mozilla.com/D28487
--HG--
extra : moz-landing-system : lando
Button elements are not user-selectable by default as defined by User Agent stylesheet defaults: https://www.w3.org/TR/css-ui-4/#issue-74a40dd9
However, by using the Selection.selectAllChildren() API, button elements do get a selection highlight (their text contents don't get copied to the clipboard; that is expected). See Bug 1546366.
Until bug 1546366 is addressed, this patch ensures that button elements in DevTools never get a selection highlight by unsetting any applied styles with the `::selection` pseudo-element.
Differential Revision: https://phabricator.services.mozilla.com/D28627
--HG--
extra : moz-landing-system : lando
Minor fixes to the layout of inputs in right-to-left (RTL) language layout. To enable RTL, navigate to `about:config` and set `intl.uidirection` to 1.
Differential Revision: https://phabricator.services.mozilla.com/D28610
--HG--
extra : moz-landing-system : lando
Reverts the icon rotation while in RTL mode for panels which always use LTR layout.
To test RTL layout, navigate to about:config and set intl.uidirection = 1
Differential Revision: https://phabricator.services.mozilla.com/D28618
--HG--
extra : moz-landing-system : lando
The server should not be driven by a client-side performance about which perf panel is enabled.
To preserve the behavior, the performance connection will not be initiated by the toolbox if the new perf panel is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D28042
--HG--
extra : moz-landing-system : lando
The test finishes correctly but it's too slow for those platforms.
There is no real added value in running this test for code coverage, because it just load tools several times.
We are not exercising a specific feature of any tool, we are rather checking for race conditions when reloading.
Skipping on code coverage should not have any impact on the actual code coverage for devtools.
Differential Revision: https://phabricator.services.mozilla.com/D28614
--HG--
extra : moz-landing-system : lando
After toggling off 'Pause on exceptions' in the debugger, exceptions were still being paused on once.
This was because the server's exception-pausing behavior was not toggled off until an exception was paused on. This patch makes it so that the behavior is changed immediately after unchecking the 'Pause on exceptions' checkbox in the debugger.
Differential Revision: https://phabricator.services.mozilla.com/D27453
--HG--
extra : moz-landing-system : lando
Depends on D27680
Not strictly related to win.top/parent, but those tests would fail if the toolbox is in a content frame.
tooltip-01.js is creating a blank tab for no reason which prevents interacting with the actual test frame.
tooltip-02.js is not properly targeting an iframe to simulate a click
Differential Revision: https://phabricator.services.mozilla.com/D27674
--HG--
extra : moz-landing-system : lando