getCssPath and getXPath will need to reuse the same logic as findCssSelector
to handle shadowDOM support.
This patch moves the methods next to findCssSelector, in toolkit's css-selector.js
to avoid duplicating logic between devtools/ and toolkit/
The content of the methods is stricltly the same, except for the Node global
not available in css-selector.js. Instead we use `ele.ownerGlobal.Node` here.
MozReview-Commit-ID: J0KuORWLUoO
--HG--
extra : rebase_source : 26a1801670e5554577f0f77b62667527f7b497bb
getCssPath and getXPath will need to reuse the same logic as findCssSelector
to handle shadowDOM support.
This patch moves the methods next to findCssSelector, in toolkit's css-selector.js
to avoid duplicating logic between devtools/ and toolkit/
The content of the methods is stricltly the same, except for the Node global
not available in css-selector.js. Instead we use `ele.ownerGlobal.Node` here.
MozReview-Commit-ID: J0KuORWLUoO
--HG--
extra : rebase_source : d6fab834be4fb6ad9ba1cd73acf960cf0fe0d4d5
This patch will remove the dotted style focusring from TabBar. We have same tab
bar in the toolbox, but this tab has removed this style already.
(For detail, see bug 1444793)
MozReview-Commit-ID: CyazZkvKR6H
--HG--
extra : rebase_source : 821e606f54bfceba124af9d9c2585296f2ebc40e
Adapt inspector test to the new order of the search results.
This was an easy task since we were already flipping the
expected results to make the test more readable (which makes
me think that this is the "natural" order).
MozReview-Commit-ID: DpxW2O1eOi4
--HG--
extra : rebase_source : 8d579c94bdaaee396a29b4674d4f9764bcadbb5d
extra : source : 96c82bb5fa591470483263aea55fa33a10192afc
For some reason, we were flipping the search result, which
was not ideal in the inspector. This patch changes this to
show results in the same order the server return them.
MozReview-Commit-ID: Ak9FnrrW8z5
--HG--
extra : rebase_source : 0846cda90ac45c70a9ee5cd49f64f1894863ec5c
Some tests needed to be adapted to the new alpa-sorted
autocomplete popup.
MozReview-Commit-ID: 3GOAJqH0CvD
--HG--
extra : rebase_source : ca9bafa6e78f2a1609618e5c258db0358a006300
The autocompletion results were flipped in order to have them in reverse
order since the popup was displayed at the top of the input.
We do not want to do that anymore because of two reasons:
- I couldn't find any example in the wild doing the same thing, thus
we were making the user switch their habit to use it
- Bug 1136299 will make it so that the popup could be displayed either
at the top or at the bottom of the caret. We shouldn't have different
sorting for those different cases as it would make the popup even
harder to use.
MozReview-Commit-ID: CAzsKIaeKgV
--HG--
extra : rebase_source : 967e43e5d86f7f35945ba5742c1a25823a2d0064
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
--HG--
extra : rebase_source : cfb2ebaaed23ce5c51ef9d8f447f3fabe0a04a49
The new "tooltip.css" file allows styling the default tooltip, which is created as native anonymous content.
MozReview-Commit-ID: ADWsFTNPfhw
--HG--
rename : toolkit/themes/linux/global/popup.css => toolkit/themes/linux/global/tooltip.css
rename : toolkit/themes/osx/global/popup.css => toolkit/themes/osx/global/tooltip.css
rename : toolkit/themes/windows/global/popup.css => toolkit/themes/windows/global/tooltip.css
extra : rebase_source : bd79b86fb44ac0dc77d0d21fdc003105da6f43eb
extra : intermediate-source : a06a200098013d5dbc42c2431f845ca1dd8b0b76
extra : source : 4d511f7fc5b5c16fdfea91242dea6086cd57c8c3
This is probably the last thing we will ship since it needs the most spec work.
MozReview-Commit-ID: LLmDBLCsCBJ
--HG--
extra : rebase_source : c06752c9201a9ede87e1ac200ab12577bf784ce6
This preference controls whether authors are allowed to specify animations
without a 0% or 100% keyframe.
We intend to ship this soon but this preference acts as a safeguard in case we
discover we need to disable it.
This feature is very convenient and commonly used so this patch ensures it is
always enabled for system content.
MozReview-Commit-ID: BHTsuS2xO61
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_implicit_keyframes.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_implicit_keyframes.html
extra : rebase_source : 04fd93dd26a4765c14b0b22febdb0311b650ea59
We don't intend to ship this in the near future until the integration with
AnimationWorklet is clear (although we might ship a read-only version).
That said, we use this feature extensively internally (e.g. in DevTools etc.) so
we enable this feature for system callers.
MozReview-Commit-ID: AhB7ZmU1Xzw
--HG--
extra : rebase_source : 630d7dc56b44a9261bb34aa5417cb9b7050efba4
This allows us to open the context menu directly from webconsole.html when it's
running as a top level window. Ultimately, I'd like to not have to use special
handling in the console - all top-level windows should get the edit menu working
automatically for HTML inputs - but this lets us prove it out as a first consumer.
MozReview-Commit-ID: BYisQDtXWe4
--HG--
extra : rebase_source : 8000147713000a30af48f1da17d50356a4cd4a04
This patch ensure that we have a consistent behavior when
the autocomplete popup is open and the user hit Enter.
We remove the autocompletePopupNavigated property which
is now useless.
We also make sure that we always show the popup when we
have at least one result (previously we needed to have
2 results to make it visible). This is again for
consistency sake and making it more obvious for the
user what will happen when hitting Enter or Tab.
Tests are modified to reflect these new behaviors.
MozReview-Commit-ID: 8QgoeU6DNk6
--HG--
extra : rebase_source : 5f62365ffaa46e12997d81bb8fe71c79f8178eb7
This will allow us to avoid regression for both versions.
Also, the test were adapted to the codeMirror jsterm.
MozReview-Commit-ID: eZBvLv7JBH
--HG--
extra : rebase_source : 445a0a81607b85d2245fb81db6563b9023796932
When migrating the old code to codeMirror, I saw that two defined behaviors
were not tested:
- ArrowLeft when popup is displayed should hide the popup and the autocompletion test
- ArrowRight when popup is displayed should complete the input with the selected element.
This patch add a test for those two cases.
MozReview-Commit-ID: HZYtHssfB55
--HG--
extra : rebase_source : 77a333a7137b233f3280cddcfc81bc3008953530
Since we are dealing with 2 versions of this component, we
introduce new helpers that abtracts how we get or assert
some values.
MozReview-Commit-ID: 1XNPcmwwsBj
--HG--
extra : rebase_source : 5b916fe9ad953ce80c058be1ea2eb8894c625c8e
This patch translates old key handlers to codeMirror ones.
MozReview-Commit-ID: FGJehgGaBGI
--HG--
extra : rebase_source : bf88130eb8e92b2bf29dac5024f0dc49f727e9c7
Create a separate function to measure the chevron width, and make
the function that measure the char width pure by only returning
the width.
The assignment to internal properties (_inputCharWidth, _chevronWidth),
is now done in componentDidMount which simplify reading this code.
MozReview-Commit-ID: FitY97Y03Sg
--HG--
extra : rebase_source : d35caaf19b14d9a5cfbddaf58d20bc6c7aeb4aaa
