We were using the onMousedown event target to select a row, based on a data-id attribute of the cell node.
But when the wrapTextInElements is true, there is an extra span element inside the cell. And in this case,
we were trying to retrieve the data-id attribute on this span, which led to calling the selection function with a
null id, and thus, not selecting the row.
We fix this by retrieving the attribute from the correct node.
A test case was added in order to make sure the bug is fixed
MozReview-Commit-ID: Jcf42AZb2uk
--HG--
extra : transplant_source : %CA%8C%DA1%AEW%0C%01%F2%97%0B%E6c%3F%DF%B3E%3A-C
The eyedropper can be shown in 2 distinct ways:
- the 'eyedropper' gcli command can be called (from the dev toolboar
or from the browser devtools menu),
- or the inspector's 'pickColorFromPage' method can be called (from
the inspector toolbar or from the color-picker in the ruleview).
Before this change, it was possible to show several eyedropper because
these 2 codepaths didn't know about each other.
Now, when executing the gcli command, the inspector's
'cancelPickColorFromPage' method is called to hide it first.
And, when the 'pickColorFromPage' method is called, the 'eyedropper --hide'
gcli command is called too.
This way, there's only one eyedropper shown.
There was also a problem where the gcli command would create a new
eyedropper everytime it was called. This was fixed too, by maintaining a
WeakMap of all eyedroppers opened so far.
MozReview-Commit-ID: F6fBP5R7ZTJ
--HG--
extra : rebase_source : f04bbf224ced7b93b4e5b0c42662731ecc58cb58
The ellipsis character displayed by devtools is now relying on a localized string
in devtools/client/shared.properties instead of a complex preference.
The lazy loading of the ellipsis string has been removed, the ellipsis is retrieved
once when the client/shared/l10n.js file is loaded.
The ellipsis property on the LocalizationHelper instances has been removed in favor
of an ELLIPSIS export on the l10n.js module.
All the previous callers using either LocalizationHelper::ellipsis or retrieving the
intl.ellipsis preference have been migrated to rely on the ELLIPSIS export of l10n.js
MozReview-Commit-ID: 4JG0qbJGCw9
--HG--
extra : rebase_source : b513f69a00335c63c46e085b0101ca4cf884fb08
extra : source : 9cea22b583c7d615be644dd50161902c35f2f1b7
Now that showing a XUL panel is asynchronous, tests need to be able to wait for the complete
initialization of the editor tooltips. Waiting for the tooltip 'shown' event is not enough
here because tooltips are also waiting for this event to start initializing their widgets.
MozReview-Commit-ID: DGTyeVrHNb
--HG--
extra : rebase_source : a99633ceb99da6dcc22dd3a5c0e737d4cfa2e36e
extra : histedit_source : 740e23053487a73c4e6d6ba97a529b2579f517d5
The eyedropper gets hidden when canceled and when selecting a color.
The Tooltip should listen to both events to update its internal state flags.
MozReview-Commit-ID: KYwmybh9mRo
--HG--
extra : transplant_source : %B2%A3o%DA%8A%8A%BA%C51%84%C6gw%5D%2B%C4%E1%D9%92%84
Using mouseleave in chrome code generates a warning in docshell about
performance which notes mouseout should be used instead. This patch replaces
usage of mouseleave with mouseout across the devtools codebase.
Scoped stylesheets cannot make reference to an element outside of the scope in any
part of a selector. This means a selector such as ".theme-light .scoped-element"
can not work in a scoped stylesheet.
Theme specific rules have been removed from the filter&bezier tooltip css. Instead
CSS variables defined for each theme are used in the scoped stylesheets.
MozReview-Commit-ID: 7apGbPc0CYy
--HG--
extra : rebase_source : e71f33b395b0a6d21bb4352507a3947ed2b81766
extra : amend_source : 55e0c78a006fd2b580d6d0e345c950a4e7ab472a
extra : source : 0be81bdc2e08b658f91dc05443ab15ced91025f2
This moves the eyedropper button from the toolbar into the inspector,
therefore the old eyedropper command isn't needed anymore,
or at least not as it was.
The button in the inspector simply uses the pickColorFromPage inspector
actor method.
And to preserve a eyedropper gcli command, a new simpler one was added.
MozReview-Commit-ID: B1yr1EqLFBD
--HG--
extra : rebase_source : 47c2effe193f4d1a64a8d16ea3609ff5ae1f793b
The color-picker tooltip now uses the new eye-dropper highlighter, by
using the pickColorFromPage inspector method instead of the XUL-based
eye-dropper tool.
Telemetry hasn't yet been re-implemented in the new eye-dropper highlighter
so the telemetry-related test code has been removed for now. This will be
added again in a later commit.
MozReview-Commit-ID: enSzSKHac4
--HG--
extra : rebase_source : dd5a54d149ac1872be8580660c70b8a02da9db66
This is mostly porting code from the XUL eye-dropper over to a new
highlighter file.
While I have tested this locally, this highlighter isn't yet used
in devtools.
This will come in later patches.
MozReview-Commit-ID: IF0puLu5Yc7
--HG--
rename : devtools/client/shared/css-color-db.js => devtools/shared/css-color-db.js
rename : devtools/client/shared/css-color.js => devtools/shared/css-color.js
extra : rebase_source : 72431a9148d1c688987a5693a619769837c774c7
Using level=float seems buggy when the window to which the XUL panel is attached
changes.
MozReview-Commit-ID: HuOnMDGo38l
--HG--
extra : rebase_source : 1445dc225e2ed5b29b187aa918980f7ffeb227b4
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
--HG--
extra : rebase_source : 5b096345c087a85f3c66fdca639287196e22775c
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
--HG--
extra : rebase_source : 57267be0d214ed807f3152838c4123400ab7b7e3
The HTMLTooltip supports an additional configuration parameter "useXulWrapper".
When set to true, if the tooltip is displayed in a XUL document, a XUL panel
will be used as an additional container for the tooltip.
This allows the tooltip to be displayed anywhere on the screen and can be
useful when displayed in small toolboxes.
MozReview-Commit-ID: 63kv4vAeW5R
--HG--
extra : source : fc4d902ff01ee92a5b6742d44286e5feaaba1500
extra : intermediate-source : 126f43ff3be5505920946a77ad82401c6bbaebef
extra : histedit_source : 863888c014723f7e95742079395497ba1a30aa36%2C13ba9aaf80acb96c587739c767c20a8f0f6a9a5a
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
The autocomplete popup is displayed relatively to an anchor, but will be
shifted on the x-axis in order to be aligned with the word being completed.
To support this, the HTMLTooltip show() method now accepts x and y offsets.
MozReview-Commit-ID: 1cR3XFPdcVy
--HG--
extra : rebase_source : 0aa84be9afe977c52bffad2eb37eb35813d8a17a
The autocomplete popup defines its width by finding the longest label
to display and then applying a "width:Xch" to its content, where X is
the length of the longest label + 3.
In order to support this, the HTMLTooltip setContent() methods allows to
use width: "auto" (which also becomes the default value). In this case,
the HTMLTooltip show() method will automatically compute the preferred
width for the tooltip. It will first calculate the tooltip height, then
measure the width of the tooltip for this computed height and use it as
the preferred width.
MozReview-Commit-ID: KDxZNB3KDdR
--HG--
extra : rebase_source : 8ceedd73434551050f8d63cbf03d66870e275b03
Some test documents are using a <page> object instead of a <window> object.
When inserting the tooltip container inside of the document, the HTMLTooltip
will now insert the container in the documentElement
MozReview-Commit-ID: F57vP2lfvrg
--HG--
extra : rebase_source : 5f99c4c139fed9a9893a98a5de2c4c3e76c753da
When calling HTMLTooltip::show() consecutively, we were leaking a window object.
The timeout responsible for attaching the click event on window is now cleared
before attaching a new one.
MozReview-Commit-ID: 3ccIHM2QNlp
--HG--
extra : rebase_source : 645e761b8fa562bfa5b8e4abe3412ef52c03c62e
setContent expects 3 arguments: content, width, height. Height is already optional
but for the autocomplete migration, the width will also become optional.
Using an object argument for width and height makes this easier.
MozReview-Commit-ID: 9CiMG0BdLOR
--HG--
extra : rebase_source : 4ec54714ccc2476fa4b341aaad3773ba095cca5a
For autofocus tooltips, we need to find a focusable item in order
to call focus() now that the tooltip content lives in the same
document as the toolbox. Updated the corresponding test and made
some superficial changes to HTMLTooltip.js.
MozReview-Commit-ID: L61eIxgFm3d
--HG--
extra : rebase_source : dae55ebb8c888638b902aec000cce2ef0631ca04
extra : source : c3ef26c17be6ef971f834c38d9aa69edc767d10c
For now this is a 1 to 1 migration of the existing Tooltip
helper method from XUL to HTML.
MozReview-Commit-ID: 9YiJLgibV9h
--HG--
extra : rebase_source : af428055060a105d270d70b1e4694717e0869b2b
extra : source : d03cca0c048c9ba1f3062519650e37ae986d4bc7
With this changeset the tooltip's effective height can be smaller than
the height specified when calling setContent. If the tooltip content is
dynamic, this allows to display a small tooltip frame if the content is
collapsed, and a bigger tooltip frame when it is expanded.
MozReview-Commit-ID: 44vA0Rdz62m
--HG--
extra : rebase_source : 0e796f611e3462579f6e84a25671e5d44ed2314d
extra : source : 8583ea99abef8f25a1822178bab823f9fb7f2d01
The existing helper checking if a click occurred inside or outside a
HTMLTooltip container was failing if the click occurred in an iframe.
MozReview-Commit-ID: 9AIACOukYUF
--HG--
extra : rebase_source : e10ce05610e9a630ed1d9ba8a3f70b3344dffe9e
extra : source : 978c01749bdc4012f010db5fe09b0f8a402a9c0e
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
--HG--
extra : rebase_source : 80a22bc558468b69ff099602ab2364a55bcdd2f7
extra : source : 1794dbc179a093b26d06eadc18086c8f138dc008
Given the current usage of the HTMLTooltip, I think having the autofocus as
an opt-in behavior makes more sense.
MozReview-Commit-ID: CS98szSKQdF
--HG--
extra : source : 626c5812f1602a257a1065a842d3f025f85452aa
Migrate the previewTooltip used in the ruleview (& computedview) to use a
HTMLTooltip instance.
Helper methods from Tooltip.js have been removed, migrated to HTML and are
now in style-inspector-overlays.js (not used by any other client). Tests
have been updated to be compatible with HTML Image preview tooltips.
The behavior should be the same as before, so no new test has been added.
MozReview-Commit-ID: HuFatuPi5VM
--HG--
extra : rebase_source : cc0f0af816c9d2a276f595120210e1e5f0197039
extra : amend_source : a6390ffac7dff0325a96be6f884b344db621b439
Rename document -> doc for consistency and parent to panel
for test compatibility.
MozReview-Commit-ID: KHT7plLtNQc
--HG--
extra : rebase_source : 3860dcef5daac2d4b2c4475043e85b7548b255a9
extra : intermediate-source : af95214eecb280ed4ad858ce6b62a3fe5d3f6a7f
extra : source : 887cbcaf18e70bc12a51b8dbdb1e9fe4aee44385
For simple rules like function spacing, we can auto-fix these across the code
base so they are followed in a consistent way.
To generate this patch, I ran:
./mach eslint devtools --no-ignore --fix
After this, I reverted any changes to third party files that we really do want
to ignore.
MozReview-Commit-ID: 6Q8BApkAW20
This patch was generated by the command:
find * -type f -exec sed -i -f ../mozpropsub {} \;
in the root of the repository, with the file ../mozpropsub containing:
s/-moz-padding-end\>/padding-inline-end/g
s/-moz-padding-start\>/padding-inline-start/g
s/-moz-margin-end\>/margin-inline-end/g
s/-moz-margin-start\>/margin-inline-start/g
s/-moz-border-end\>/border-inline-end/g
s/-moz-border-end-color\>/border-inline-end-color/g
s/-moz-border-end-style\>/border-inline-end-style/g
s/-moz-border-end-width\>/border-inline-end-width/g
s/-moz-border-start\>/border-inline-start/g
s/-moz-border-start-color\>/border-inline-start-color/g
s/-moz-border-start-style\>/border-inline-start-style/g
s/-moz-border-start-width\>/border-inline-start-width/g
s/\<MozPaddingEnd\>/paddingInlineEnd/g
s/\<MozPaddingStart\>/paddingInlineStart/g
s/\<MozMarginEnd\>/marginInlineEnd/g
s/\<MozMarginStart\>/marginInlineStart/g
s/\<MozBorderEnd\>/borderInlineEnd/g
s/\<MozBorderEndColor\>/borderInlineEndColor/g
s/\<MozBorderEndStyle\>/borderInlineEndStyle/g
s/\<MozBorderEndWidth\>/borderInlineEndWidth/g
s/\<MozBorderStart\>/borderInlineStart/g
s/\<MozBorderStartColor\>/borderInlineStartColor/g
s/\<MozBorderStartStyle\>/borderInlineStartStyle/g
s/\<MozBorderStartWidth\>/borderInlineStartWidth/g
The diffs for the following files:
layout/style/nsCSSPropAliasList.h
layout/style/test/property_database.js
layout/style/test/test_value_computation.html
were then manually removed from the patch.
MozReview-Commit-ID: 8fbYnlZcn9U
First implementation of HTML based tooltip to be used in devtools
instead of XUL panels. API is similar to the current API of
Tooltip.js
MozReview-Commit-ID: 8njiKBubLSj
--HG--
extra : rebase_source : 930bf7aef48e6c16d7a560d261e2bfd06fe02a63
extra : source : 09874a1e6f2c942a1f9de827fedd14da7e67a6e5
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
--HG--
extra : rebase_source : 279bab30f631a3a65a93b52226c6980210abf2f1
The code used to make the tooltip appear/disappear when hovering targets
has been extracted to a separate class that can be shared between the
current Tooltip.js implementation and the upcoming HTMLTooltip.
MozReview-Commit-ID: UYSjPFeMYK
--HG--
extra : rebase_source : 5dcca2d5887ffc98fec621092640073a0909c13f
