Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
Also, only show the element highlighter when the "objectBox-node" is hovered,
like we do in the console.
Tests are updated to assert the new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D295750
container queries can now have multiple conditions, so we're computing those
on the server and sending it to the client, where we render them separately.
As each condition might refer to a different container, we need to update how
we were handling hovering the container query to show the container tooltip.
Before, we were underlining the `@container` part plus the eventual container
name; now, we underline the whole condition (eventual container name + eventual
container query).
This also impacts how we were triggering the box model highlighter for the container,
it is now displayed when the tooltip is visible, and the tooltip is actually
responsible to toggle it.
The tooltip code is also tweaked so we would always show the tooltip based on
the condition element, not any of its children (e.g. the jump button).
And since we were updating things here, we now add a tooltip-anchor class to
the element that is used as the anchor for the tooltip, so it can be styled.
In this case, we use it to have the same style as we put on hover on the condition
so things feels a bit more stable.
Finally, in order for us to get the proper container, we had to update
`CSSContainerRule.queryContainerFor` in the previous patch so it would know which
condition we should get the container for.
This patch now properly pass the condition index to the RDP method, and the server
functions pass it to `CSSContainerRule.queryContainerFor`.
Differential Revision: https://phabricator.services.mozilla.com/D291482
Three callers:
* fixed attribute is only used as fixed=true for treecolumns, so no
behavior change.
* noautofocus is already only used as =true or removed, so no behavior
change.
* incontentshell is only used with ="false", rename to
escapecontentshell and flip the meaning.
Remove the API and similar GetXUL* stuff that did the same.
Differential Revision: https://phabricator.services.mozilla.com/D286520
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
Emilio Cobos Álvarez