Stepping through the test, the content is not re-inserted on reload.
I think a perma failing test checking a non-existent feature should be removed, it's just debt at this point.
Differential Revision: https://phabricator.services.mozilla.com/D297052
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
The player word is a relic of a past implementation of the Animation API that doesn't
exist anymore.
This patch removes/renames references to player that are easy to handle.
Renaming RDP methods / fronts will be done later in following commits.
Differential Revision: https://phabricator.services.mozilla.com/D289496
The `gBrowser.reloadTab` method was doing a very light reload,
which could preserve iframe overriden locations.
The new method ensures we load the original HTML content back,
this seems to also have an impact on keep-alive which is not longer guaranteed.
Only supports reloading the currently selected tab, to better replicate
real user scenarios. But also to comply to `BrowserCommands.reload`,
which only supports reloading the selected tab.
Also tune the har test, now that requests are really cancelled
and we may try to fetch reponse content for such request.
Differential Revision: https://phabricator.services.mozilla.com/D277433
`AnimationActor` `pauseSome`, `playSome`, `setCurrentTimes` and `setPlaybackRates`
all take an array of `AnimationPlayerActor` instances for which we'll perform
some operation on their underlying animation.
It can happen that some of those actors are not handled by the `AnimationsActor`
anymore (e.g. the animation stopped, but the client wasn't updated yet).
Performing any action on those unhandled player (pausing, setting time, …) might
actually trigger a new, unwanted, mutation, which will cause both the server
state and the client state to be out of date.
This patch filters out actors which are not into `AnimationsActor#actors` to avoid
such issue.
Differential Revision: https://phabricator.services.mozilla.com/D273562
In the class, there were a couple places where we would check the animation target
`type` property as a way to detect if the animated element was a pseudo element.
This means that we were considering button elements as pseudo element, and re-assigning
variables with erroneous properties, which would ultimately make the methods throw.
This is also wrong for pseudo elements: the animation target is always the binding
element and we have a `pseudoElement` string property on the animation to detect
if this applies to a pseudo element.
We fix the faulty callsites and add a server test that is covering this.
Differential Revision: https://phabricator.services.mozilla.com/D273546
Remove devtools/shared/layout/utils.js isNativeAnonymous/isAnonymous and switch
callsites to directly use node.isNativeAnonymous getter.
On the client rename isAnonymous into isNativeAnonymous so it's consistent
with the platform implementation.
Differential Revision: https://phabricator.services.mozilla.com/D271553
We used to compute the pseudo element name (e.g. `::before`, `::marker`, …) in a
few places, both on the server and the client.
This patch does it directly from `getNodeDisplayName`, which is called for assigning
the NodeActorForm displayName.
We also use `getNodeDisplayName` in `getBindingElementAndPseudo` to avoid duplicating
code.
On the client we now use displayName in the few places we used to re-construct
the pseudo element text in (markup view, breadcrumb, rules view, …)
We also no longer pass "individual" pseudo element booleans (e.g. `isAfterPseudoElement`)
in the NodeActor form, but a more generic `isPseudoElement` one so it's easier
to handle future pseudo element (e.g. `::view-transition`).
And we take this as an opportunity to remove the utility functions that we were
using to build those properties, and instead switch to look into `Node.implementedPseudoElement`
to detect when we do handle pseudo elements.
Differential Revision: https://phabricator.services.mozilla.com/D271002
We used to compute the pseudo element name (e.g. `::before`, `::marker`, …) in a
few places, both on the server and the client.
This patch does it directly from `getNodeDisplayName`, which is called for assigning
the NodeActorForm displayName.
We also use `getNodeDisplayName` in `getBindingElementAndPseudo` to avoid duplicating
code.
On the client we now use displayName in the few places we used to re-construct
the pseudo element text in (markup view, breadcrumb, rules view, …)
We also no longer pass "individual" pseudo element booleans (e.g. `isAfterPseudoElement`)
in the NodeActor form, but a more generic `isPseudoElement` one so it's easier
to handle future pseudo element (e.g. `::view-transition`).
And we take this as an opportunity to remove the utility functions that we were
using to build those properties, and instead switch to look into `Node.implementedPseudoElement`
to detect when we do handle pseudo elements.
Differential Revision: https://phabricator.services.mozilla.com/D271002
In most cases, the manifest contained already the same annotation for 2404, so I simply removed the 1804 one, since we no longer run tests on this platform.
In a few cases, the 1804 annotation did not have a 2404 match. In that case I just checked if we had recorded intermittent failures. If yes, I migrated the annotation, if not, I just removed it.
Differential Revision: https://phabricator.services.mozilla.com/D271355
After bug 1938624, <input type=search> has a separate searchbox role from the role used for other text inputs.
Update DevTools accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D270982
When provided, this will add a class to the anonymous content root host.
We pass it from the different highlighters so it's easier to spot a given
highlighter when inspecting a page.
Differential Revision: https://phabricator.services.mozilla.com/D260264
Explicitely setting the final id/class from the callsite to createNode is better for search,
and overally maintainability in the long run.
Differential Revision: https://phabricator.services.mozilla.com/D259527
We used to check if the passed query looked like a tag name so we could
bail out early, as we'd get those results from _searchIndex.
But InspectorUtils.isCustomElementName does match some legitimate
selectors, like div.a-b.
Let's remove the check on custom element and trigger the search in such case.
Differential Revision: https://phabricator.services.mozilla.com/D259783
This removes the implementation of nsHTMLButtonControlFrame, instead
reusing nsBlockFrame + align-content (or the relevant display type for
flex / grid / columns / etc).
This matches what Blink does and, for the most part, it is trivial.
It requires moving some special cases around, and override inline flow
display, tho so that buttons don't suddenly start fragmenting in the
inline axis.
It adds a tiny fix for a writing-mode mismatch in
nsBlockFrame::AlignContent(), covered by
layout/reftests/writing-mode/1138356-1-button-contents-alignment.html
containing-block-change-button tests are tweaked to avoid overflowing
the 600px viewport from WPT reftests causing scrollbar fuzziness.
contain-layout-baseline-005.html removes the <select> element just like
https://chromium-review.googlesource.com/c/chromium/src/+/5479489
removed the <button>s, since they align the same now, added a test for
that.
Differential Revision: https://phabricator.services.mozilla.com/D257149
Nicolas Chevobbe