Set useXulWrapper to true for markup view image previews and rule view
tooltips.
Also slightly changed the logic in HTMLTooltip.js so that useXulWrapper is only
true when we are in a XUL context.
MozReview-Commit-ID: 9EkQYLLAn7C
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
In order to have tooltips with a variable height, the tooltip container
should be allowed to resize itself on the fly, which cannot be achieved
with an iframe.
This changeset makes the HTMLTooltip rely on a HTML container inserted
in the XUL document directly. This allows to go back to a synchronous
API which also simplifies the implementation.
MozReview-Commit-ID: EDcsnVSKmeU
The markup view will now inline a textnode in its container if and only if:
- the text node is the only child (pseudo elements included)
- the text node length is smaller than a predefined limit
If a container is expanded, its text nodes will now always be rendered in full,
no longer as a short version with an ellipsis. When selecting or navigating on
a textnode, the layout will no longer be modified on the fly.
MozReview-Commit-ID: HcDMqjbOesN
The markup view will now inline a textnode in its container if and only if:
- the text node is the only child (pseudo elements included)
- the text node length is smaller than a predefined limit
If a container is expanded, its text nodes will now always be rendered in full,
no longer as a short version with an ellipsis. When selecting or navigating on
a textnode, the layout will no longer be modified on the fly.
MozReview-Commit-ID: HcDMqjbOesN
In preparation for using the HTML Tooltip in the markup view, we use now
a different tooltip instance for the image previews.
MozReview-Commit-ID: EOoVg6Syntj
In bug 1270462 we changed the expected return value of the hover callback
used for the toggle tooltips. All callbacks were migrated except one in
markup.js. This changeset fixes this as well as a test which was depending
on it.
MozReview-Commit-ID: 1FZmxT6gIoS
Add a displayName property on the NodeActor, which compute from Element.prefix + Element.localName.
The computation is made by a getNodeDisplayName function which can be imported wherever needed.
Edit some tests to ensure we correctly display node names.
MozReview-Commit-ID: 6z0G3ynbMoU
Previously, the targetNodeCb used in TooltipToggle had an inconsistent API. If
returning synchronously, "false" would prevent the tooltip from appearing.
However, if using a promise, resolving "false" would still show the tooltip.
It was needed to reject the promise in this case to prevent the tooltip from
being displayed.
This commit makes TooltipToggle always expect a consistent return value from
this callback, whether it is synchronous, or using promises.
- true -> show the tooltip on the event target
- DOM node -> show the tooltip on the provided node
- false (or falsy value) -> do not show the tooltip
MozReview-Commit-ID: 7PIPwBJxjWO
Though, if the element has pseudo-elements, and thus can be expanded, show
the closing tag when the void element is expanded.
MozReview-Commit-ID: 7UMMlVjYqLX
ESLint 2 now flags anonymous generator functions according to
generator-star-spacing. Most of the changes here are correcting that.
MozReview-Commit-ID: 9xg2Gmlaz94
The inplaceEditor now supports a maxWidth configuration option which can either
be a number or a method returning a number. This maxWidth will be applied to the
hidden element used in order to autosize the input.
MozReview-Commit-ID: JTiCQ3HK5bn
Bail out from the markup view onKeyDown handler if any modifier is currently
true. All shortcuts specified in this handler are intended to be used without
modifier, so for now this approach is fine.
Added a test checking the use case mentioned in Bug 1230325, with the S
shortcut. In order to write the test, had to create an additional method on
the test actor to be able to wait for events in the window of the content process.
MozReview-Commit-ID: 67icou0HkfA
