The item to focus after hiding the popup was picked from the tooltip document,
but picking it in the anchor document sounds more appropriate.
Also avoid to re-set the focus if the tooltip document doesn't have the focus
anymore before hiding the console (e.g. the user clicked on something outside
of DevTools)
This allows to properly focus the event badge back when hiding the event listener
tooltip with the keyboard. We tweak the event badge focus style a bit to make
this more obvious.
Differential Revision: https://phabricator.services.mozilla.com/D216909
This adds proper borders and radii on Windows and Linux, which are
otherwise not present, and simplifies a bit the code by using the same
code path across platforms, and between HTML and XUL.
Remove some ::-moz-focus-inner styles which no longer apply to un-themed
buttons.
The extra -0.5 offset I think was compensating for the margins and
missing border-box sizing.
Differential Revision: https://phabricator.services.mozilla.com/D197793
The "tooltip-visible" class name is set *before* registering the click listener
which is fired by the test just after this event is received. Not surprising this caused such race condition.
I imagine we may face this race condition in any test listening for tooltip-visible.
I tried firing tooltip-visible later, like tooltip-shown, but it caused non trivial failure in other tests.
We would need to migrate usage of tooltip-visible one by one to moving forward with only oneevent.
Differential Revision: https://phabricator.services.mozilla.com/D192823
menupopup elements created for select widgets will not be children of the select itself.
Therefore the check in HTMLTooltip to ignore events if they are triggered from within the tooltip container is not working.
There is no straightforward way to link the select to its popup, and we also can't do a coordinate check (because the menupopup might expand outside
of the initial tooltip), so for now we just ignore all events coming from a menupopup element.
A browser mochitest for the filter widget has been modified to verify this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D167805
This will help transition to ES Modules as this symbol is exposed to them.
$ sed -ie "/require(.Services.)/d" $(git grep -l 'require("Services")' devtools/)
$ sed -ie "/loader.lazyRequireGetter(this, .Services./d" $(git grep -l 'loader.lazyRequireGetter(this, "Services"' devtools/)
+ the edition of builtin-modules.js + eslintrc.js
+ manual eslint fixes
+ removal of devtools-services in the debugger, except for jest tests
Differential Revision: https://phabricator.services.mozilla.com/D156401
The screen coordinates are already correctly relative to this.doc
because we use getBoxQuads() appropriately.
The only reason we needed to multiply by the zoom value was because the
popup code was incorrectly unaccounting for it. Now that screen
coordinates all make sense and include zoom this is unneeded.
This fixes devtools/client/framework/test/browser_toolbox_zoom_popup.js
with the patch here.
MANUAL PUSH: Backout-avoiding orange fix CLOSED TREE
We used to clear a timeout in HTMLTooltip which is supposed to resolve a Promise
when it's executed, meaning that we could end up with Promises that would never
resolve.
In the test itself, we wait for a tick between each loop iteration and after hiding
the popup to make sure everything has the time to be painted.
Differential Revision: https://phabricator.services.mozilla.com/D83912
There are currently cases where the HTMLTooltip would "jump"
when its content is updated whereas it shouldn't, as when
applying those result to CSS, decimals aren't taken into
account (so a "left" of 152.9999 would translate into a
CSS "left" property of 152px).
Rounding those values seems to fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D66576
If the XUL wrapper was opened and a consumer called show again,
the panel wouldn't update its position. This can be fixed by checking the
state of the element, and if it's open move the panel using `_moveXulWrapperTo`.
With this change in place, we can remove the updateContainerBounds methods,
as it has the same arguments and is only used in one place.
Differential Revision: https://phabricator.services.mozilla.com/D63488
If the XUL wrapper was opened and a consumer called show again,
the panel wouldn't update its position. This can be fixed by checking the
state of the element, and if it's open move the panel using `_moveXulWrapperTo`.
With this change in place, we can remove the updateContainerBounds methods,
as it has the same arguments and is only used in one place.
Differential Revision: https://phabricator.services.mozilla.com/D63488
If the XUL wrapper was opened and a consumer called show again,
the panel wouldn't update its position. This can be fixed by checking the
state of the element, and if it's open move the panel using `_moveXulWrapperTo`.
With this change in place, we can remove the updateContainerBounds methods,
as it has the same arguments and is only used in one place.
Differential Revision: https://phabricator.services.mozilla.com/D63488
If the XUL wrapper was opened and a consumer called show again,
the panel wouldn't update its position. This can be fixed by checking the
state of the element, and if it's open move the panel using `_moveXulWrapperTo`.
With this change in place, we can remove the updateContainerBounds methods,
as it has the same arguments and is only used in one place.
Differential Revision: https://phabricator.services.mozilla.com/D63488
The positioning of the arrow was correct, but due to the way the arrow was rotated, the visual center of the arrow did not match the center of the arrow box
Backing out the JS change here, CSS patch later in the queue
Differential Revision: https://phabricator.services.mozilla.com/D52668
Depends on D46958
The getTopWindow logic was duplicated between DevToolsUtils and HTMLTooltip.
This removes the duplication and adds a fixture to the accessibility panel to avoid loading the actual DevToolsUtils file in jest tests.
Differential Revision: https://phabricator.services.mozilla.com/D46959
Also changed the border radius to be consistent between doorhanger and arrow style tooltips.
There are still subtle differences between the XUL+arrow/HTML+arrow/XUL+doorhanger, but for now I would just like to fix this before we merge to 70.
Strictly using the photon shadow for doorhangers is too subtle and too inconsistent with our other tooltips, so I used shadow-20.
Differential Revision: https://phabricator.services.mozilla.com/D36767
### 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
If we displayed the devtools across the second screen, the Screen.availLeft
might be not zero. I.e., Screen.availLeft point to second screen's left.
The HTMLTooltip does't consider this case, so this patch will change the
viewpor's left and right position if the left of anchor element is bigger than
screen.right.
Differential Revision: https://phabricator.services.mozilla.com/D8183
Nicolas Chevobbe