Due to how highlighters work, it requires the inspector to be initialized.
It can happen than the user will mouseenter/mouseout on an element that
calls highlight/unhighlight very quickly.
Since the hightlight can take some time, it might happen that the unhighlight
call is handled first, before the highlight call, meaning that we now have an
highlighter displayed, even though the user isn't hovering anything that
should cause this anymore.
This patch introduces a new toolbox function called `getHighlighter` that
returns an object with a `highlight and a `unhighlight` function.
We keep a reference to any possible pending `highlight` call so we can wait
for it to be done in `unhighlight`, before destroying it.
The console makes use of the new helper function, and a test is added to ensure
we don't have zombie highlighters anymore.
Differential Revision: https://phabricator.services.mozilla.com/D34562
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
this is the weird one. we have a Debugger.executeSoon call for the destruction of the host.
However, before this happened immediately after the test closed. Now, it happens a little later, and
this messes up the data set up. The comment says that we cannot remove this.
Differential Revision: https://phabricator.services.mozilla.com/D32722
--HG--
extra : moz-landing-system : lando
this is the weird one. we have a Debugger.executeSoon call for the destruction of the host.
However, before this happened immediately after the test closed. Now, it happens a little later, and
this messes up the data set up. The comment says that we cannot remove this.
Differential Revision: https://phabricator.services.mozilla.com/D32722
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
We also listen for the warningGroup preference change to
toggle warningGroups in the console output.
If warningGroups were disabled, we need to loop through
the state messages to create warningGroups when needed.
A test is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D32716
--HG--
extra : moz-landing-system : lando
These are generally:
- Code comments to browser.xhtml
- Testcases, assertions that were mostly using browser.xul as a generic chrome URL
- References to the browser.xul path in tree
Differential Revision: https://phabricator.services.mozilla.com/D33208
This is the first part of getting rid of framework/attach-thread.js -- here we move the
toolbox related logic back into the toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D29193
--HG--
extra : moz-landing-system : lando
As per the bug description, this removes some old code that relied on the target
re-emitting threadClient events. Now we simply listen to the threadClient events directly.
Differential Revision: https://phabricator.services.mozilla.com/D29162
--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
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
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
