This test will check the following:
* Open / Close the meatball menu with click the button.
* Handling the keys. (Up / Down / Home / End)
* Close the meatball menu with F1 key.
* Close the meatball menu with Escape key.
Differential Revision: https://phabricator.services.mozilla.com/D3592
--HG--
extra : moz-landing-system : lando
The completion node was wrongly positioned as soon as the input overflowed.
We fix this by setting the completionNode height in resizeInput,
like we do for the inputNode.
The inputNode takes the whole remaining vertical space
when starting the console. But when typing, the height
is computed and set according to what's in the input.
Which means the input wasn't taking the remaining space
anymore, which could be weird (e.g. if the user wants
to select some text by starting dragging below the actual
input, although the UI would indicate it is possible).
The autocompletionPopup was a bit off due to 2 things:
- in the function that was returning the chevronWidth, we
were subtracting the autocomplete popup padding. But the
autocomplete popup already handles that itself.
- in the function that was computing the character width,
we were using offsetWidth which returned a rounded value.
This means that the further the autocompletion was displayed
at, the more the popup would be off. We use getBoundingClientRect().width
instead which gives us a decimal value.
And we also make sure to not alter the scrolling position in the inputNode
when accepting an autocompletion result (a test is added).
Differential Revision: https://phabricator.services.mozilla.com/D4207
--HG--
extra : moz-landing-system : lando
In Bug 1478435 a selector was removed causing the background
of the SearchBox autocomplete to be transparent and without
box-shadow.
This patch add the needed rule in the CSS. We take this as an
opportunity to fix a small positioning issue by making sure
the element stick to the left.
Differential Revision: https://phabricator.services.mozilla.com/D4421
--HG--
extra : moz-landing-system : lando
These were used when we were working on the HTML version of the frontend, but now
we don't even ship the XUL version, and these properties got missed during removal.
Differential Revision: https://phabricator.services.mozilla.com/D4463
--HG--
extra : moz-landing-system : lando
It's broken and unmaintained for a long time now,
the Console Team does not use it and has no plan doing so.
Differential Revision: https://phabricator.services.mozilla.com/D4348
--HG--
extra : moz-landing-system : lando
If the autocomplete only returns 1 item, we usually close the
popup and show the autocompletion text.
But in some cases the autocompletion text can't be shown (e.g.
there's some text after the cursor). So we end up showing
nothing for the user, which is not ideal.
In such case, this patch ensures we do show the popup so the
user can autocomplete and save some keystrokes.
Depends on D4061
Differential Revision: https://phabricator.services.mozilla.com/D4335
--HG--
extra : moz-landing-system : lando
This patch adds a smarter heuristic for autocompletion results:
if the input first letter is lowercased, then we'll filter
matching properties case insensitively. But if the user starts
with an uppercase, we assume they know the property they want
and thus respect the casing.
For example: `win` will return both `window` and `Window`, but
`Win` will return `Window` only.
Due to this behavior, we change the order of the autocomplete
results so lowercased property are displayed before the uppercased
one.
If we take are example again, it's likely that if a user type `win`,
they want `window`, but the alphabetical order would return `Window`
first which would annoy user.
Now, since we return results that does not match exactly the user
input, we need to modify the frontend.
Usually, we only show the autocompletion popup if there are
at least 2 matching items, since 1 matching item will still
be displayed using the autocompletion text. But now, since the
input might not match, we want to still display the popup if
there is one matching item, but starts differentely than what
the user entered.
For example, the user typed `window.addeve`, which matches
`addEventListener`. The completion text will make it looks like
it will be completed to `window.addeventListener`, which would
be undefined. So showing the popup with the actual matching
property might avoid some confusion for the user.
A test was added to make sure the frontend works as expected.
Some test cases were added in the server test to make sure
the actor returns expected results. Other tests needed some
adjustement because of the insensitive case matches and the
new order of results.
Differential Revision: https://phabricator.services.mozilla.com/D4061
--HG--
extra : moz-landing-system : lando
- increase delay before auto-increment starts and between iterations.
- ensure auto-increment happens only when *dragging and holding* the slider thumb.
- ensure auto-increment works consistently when switching from number input directly to slider.
Depends on D4225
Differential Revision: https://phabricator.services.mozilla.com/D4226
--HG--
extra : moz-landing-system : lando
This patch introduces a screenshot actor, which allows the screenshot functionality to be
shared across tools, and also implements it for the toolbox itself
Differential Revision: https://phabricator.services.mozilla.com/D3341
--HG--
rename : devtools/server/actors/webconsole/screenshot.js => devtools/shared/screenshot/capture.js
rename : devtools/shared/webconsole/screenshot-helper.js => devtools/shared/screenshot/save.js
extra : moz-landing-system : lando
In https://github.com/devtools-html/debugger.html/pull/6809 a check
was removed in the Tree component because seens as unnecessary, and
a test was modified to accomodate the change. Turns out the test was
needed in its original form, and was surfacing a bug.
This patch rolls back both the change in the Tree component _and_ in
the test.
The Tree modification will be backported to the Github repository.
Differential Revision: https://phabricator.services.mozilla.com/D4307
--HG--
extra : moz-landing-system : lando
Roll our own validation because Firefox number inputs are unreliable.
Use internal state for the inputs while the user is typing.
Revert to valid values on blur if necessary.
Reconcile internal state with outside props on blur.
Differential Revision: https://phabricator.services.mozilla.com/D4225
--HG--
extra : moz-landing-system : lando
