This will automatically add all the necessary event listeners
for the autocomplete (navigating, selecting an item, closing).
The input will also be used as a default anchor when showing
the popup.
Differential Revision: https://phabricator.services.mozilla.com/D72859
This will automatically add all the necessary event listeners
for the autocomplete (navigating, selecting an item, closing).
The input will also be used as a default anchor when showing
the popup.
Differential Revision: https://phabricator.services.mozilla.com/D72859
Previously, the list clone was completely replaced every time aria-activedescendant was set.
This caused screen readers to extraneously report this as a new list every time the user cursored to a different item, even if the items hadn't changed.
Differential Revision: https://phabricator.services.mozilla.com/D79941
This prevents the popup to cover the eager evaluation result.
In order for the popup to be able to appear outside of the
toolbox, we pass the useXulWrapper option to the HTMLTooltip.
Differential Revision: https://phabricator.services.mozilla.com/D62431
This prevents the popup to cover the eager evaluation result.
In order for the popup to be able to appear outside of the
toolbox, we pass the useXulWrapper option to the HTMLTooltip.
Differential Revision: https://phabricator.services.mozilla.com/D62431
This prevents the popup to cover the eager evaluation result.
In order for the popup to be able to appear outside of the
toolbox, we pass the useXulWrapper option to the HTMLTooltip.
Differential Revision: https://phabricator.services.mozilla.com/D62431
This patch will remove setContest(), and change the following things instead of this:
* Use HTMLTooltip.panel.appendChild() instead of HTMLTooltip.setContent().
* Add HTMLTooltip.setContetnSize() to specify the panel size if need this.
Differential Revision: https://phabricator.services.mozilla.com/D7044
This patch introduces some options that can be passed to
setItems and openPopup to prevent doing unecessary work.
The main ideas here are to create all the popup items and
put them in a document fragment which then will be appended
to the popup, so we don't add them one by one which can be costly.
When creatingthe items, we also create one directly with the
selected class if autoSelect is set to true. This way, we don't have
to toggle the class later (which led to another reflow).
We take this work as an opportinuity to clean up the component.
Unused function (like appendItem and removeItem) are removed,
selectedIndex does not use a getter/setter anymore.
Some of the consumers calls are updated and so is the component test.
Differential Revision: https://phabricator.services.mozilla.com/D4848
This patch introduces some options that can be passed to
setItems and openPopup to prevent doing unecessary work.
The main ideas here are to create all the popup items and
put them in a document fragment which then will be appended
to the popup, so we don't add them one by one which can be costly.
When creatingthe items, we also create one directly with the
selected class if autoSelect is set to true. This way, we don't have
to toggle the class later (which led to another reflow).
We take this work as an opportinuity to clean up the component.
Unused function (like appendItem and removeItem) are removed,
selectedIndex does not use a getter/setter anymore.
Some of the consumers calls are updated and so is the component test.
Differential Revision: https://phabricator.services.mozilla.com/D4848
This removes the border-radius from the autocomplete popup (and
its items) and refines the spacing.
Since we have more padding for the autocomplete items, we need
to adjust the xOffset when showing the popup.
The yOffset of the webconsole autocomplete is tweaked a bit so
we see its border; the xOffset of the markup search input is also
tweaked to consider the left padding we use to display the search
icon in the input.
MozReview-Commit-ID: JyLySLBUgGy
Previously, we were trying to select the item the closest
to the input used for the autocompletion. It was causing
some weird behaviour when the popup wasn't displayed at
the expected position.
Always selection the top-most item seems will avoid those
cases, bring us consistency across the toolbox as well as
with other tool having autocompletion (code editors, Chrome, …).
The autocomplete-popup test is modified to assert the new behavior.
MozReview-Commit-ID: DhNovX51KRO
This leaves getAdjustedQuads alone because it lives in its own world and its
result gets sent over IPC. That leaves things in a bit of an intermediate
state, but that should be OK for now.
MozReview-Commit-ID: DH6eGqCFhPr
Devtools autocomplete popups are hosted in a different document from the input
being autocompleted. To allow accessibility tools such as screen readers to still
make sense of this widget, a clone of the suggestion list is now inserted in the same
document as the input, and the aria-activedescendant attribute is updated on the input
accordingly.
MozReview-Commit-ID: 8rFjF6nvEyU
Modify the devtools autocomplete-popup to rely on a HTMLTooltip instance
instead of a XUL panel.
Other than the straightforward migration to HTML, the main difference with
the new implementation is that the richlistbox has now been replace with a
simple HTML list element. The former XUL widget used to be able to take the
focus from the input it was linked to.
This is no longer the case. Most autocomplete users were always keeping the
focus in the input, except for the inspector-search, which was moving the
focus back and forth between the input and the autocomplete's richlistbox.
Now the focus is always in the input. A practical example to illustrate how
this changes the UX: before when the user had the focus on the first element
of the list, pressing "DOWN" would keep the element selected but visually move
the focus in the input. Now the selection simply cycles to the next item.
Even though this introduces a difference in behaviour compared to the previous
implementation, it makes the inspector search UX consistent with the other
autocomplete widgets used in devtools.
Another difference is about the display for the inspector-search. The position
of the autocomplete popup used to be above the input. This is now impossible to
achieve because the search input is at the top of the toolbox and the HTML tooltip
can not exceed the limits of the toolbox.
For this #2 issue, either we manage to use XUL panel wrappers, in which case, the
autocomplete will be displayed as it used to. Or we can invert the order in which
items are inserted and explicitly ask for the autocomplete to be displayed below the
input. I prefered not to change this here in order to make the code change easier to
understand, but it should be addressed in a follow-up.
MozReview-Commit-ID: jH9aXm9Jvz
