This implements the focus behavior described in [1]:
1. Moves focus from an invoking element to its invoked popover,
regardless of where in the DOM that popover lives.
2. Moves focus back to the next focusable element after the
invoking element once focus leaves the invoked popover.
3. Skips over an open invoked popover otherwise.
[1] https://html.spec.whatwg.org/#focus-navigation-scope-owner
Differential Revision: https://phabricator.services.mozilla.com/D190560
This implements the focus behavior described in [1]:
1. Moves focus from an invoking element to its invoked popover,
regardless of where in the DOM that popover lives.
2. Moves focus back to the next focusable element after the
invoking element once focus leaves the invoked popover.
3. Skips over an open invoked popover otherwise.
[1] https://html.spec.whatwg.org/#focus-navigation-scope-owner
Differential Revision: https://phabricator.services.mozilla.com/D190560
This implements the focus behavior described in [1]:
1. Moves focus from an invoking element to its invoked popover,
regardless of where in the DOM that popover lives.
2. Moves focus back to the next focusable element after the
invoking element once focus leaves the invoked popover.
3. Skips over an open invoked popover otherwise.
[1] https://html.spec.whatwg.org/#focus-navigation-scope-owner
Differential Revision: https://phabricator.services.mozilla.com/D190560
This implements the focus behavior described in [1]:
1. Moves focus from an invoking element to its invoked popover,
regardless of where in the DOM that popover lives.
2. Moves focus back to the next focusable element after the
invoking element once focus leaves the invoked popover.
3. Skips over an open invoked popover otherwise.
[1] https://html.spec.whatwg.org/#focus-navigation-scope-owner
Differential Revision: https://phabricator.services.mozilla.com/D190560
This implements the focus behavior described in [1]:
1. Moves focus from an invoking element to its invoked popover,
regardless of where in the DOM that popover lives.
2. Moves focus back to the next focusable element after the
invoking element once focus leaves the invoked popover.
3. Skips over an open invoked popover otherwise.
[1] https://html.spec.whatwg.org/#focus-navigation-scope-owner
Differential Revision: https://phabricator.services.mozilla.com/D190560
This patch shouldn't change behavior. It just removes a lot of noise
from that function.
In particular, it simplifies various conditions that can't happen, like
startNode being a text-node but a form control at the same time, or a
text-node and the root element.
Differential Revision: https://phabricator.services.mozilla.com/D186964
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
It may dispatch `focus` event to the document node or the DOM window first.
Then, the web app may set another window focused or may move the focusing
element to another document. In these cases, the method should not keep
handling it. And unfortunately, it's hard to keep setting focus to the
focusing element after it's moved to another document because it'll cause
dispatching another `focus` event on the new document and window even if we
call itself recursively. Then, it could cause infinite loop. As far as
I've checked the behavior in Chrome for Windows, Chrome does not keep setting
focus. Thus, we can just stop moving focus in the case.
Differential Revision: https://phabricator.services.mozilla.com/D175845
`IMEStateManager` basically runs at focus change. However, when `designMode`
is set to `"off"` or focused editing host becomes non-editable (removing
`contenteditable` attribute or `contenteditable` attribute is set to `false`),
IME may be disabled without a focus change. Therefore, `Document` needs to
notify `IMEStateManager` of the timing.
Additionally, `nsFocusManager` does not change focus when focused element
becomes not focusable (bug 1807597). Therefore, `Document` needs to kick
`focus` or `blur` event handler of `HTMLEditor` when active editing host
becomes not editable.
However, if an ancestor of focused element becomes editable, I think that
`HTMLEditor` does not work well without focus move because it computes
editing host with current editing state in a lot of places, but `Selection`
and `nsFocusManager::GetFocusedElement` keeps working with previous focused
element which is now a editable child of editing host. Therefore, this patch
marks them as `todo` in the new tests.
Differential Revision: https://phabricator.services.mozilla.com/D171196
This fixes an issue where Element::Focus triggered another focus
event and caused the initial focus event failed to be executed.
Differential Revision: https://phabricator.services.mozilla.com/D163156
This fixes an issue where Element::Focus triggered another focus
event and caused the initial focus event failed to be executed.
Differential Revision: https://phabricator.services.mozilla.com/D163156
Ensuring that the date input within a main browser is not loosing focus when its associate date picker panel is opened and that the focus is udpated accordingly when it is closed (main part of the patch was crafted by Emilio, tests are added by ayeddi).
Differential Revision: https://phabricator.services.mozilla.com/D167698
FlushAndCheckIfFocusable does a few things in the same function, however
I'd like to reuse the area and shadow dom checks from it for the
autofocus algorithm work. Generally they are useful for checking if a
non-focusable element can be focused.
Differential Revision: https://phabricator.services.mozilla.com/D168399
No implementation of nsIDOMXULMenuListElement returns an input field
(this is menulist.js and autocomplete-input.js).
It seems autocomplete-input used to do this, but it got refactored to
extend HTMLInputElement instead, so this code can all go.
Differential Revision: https://phabricator.services.mozilla.com/D169066
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
The blur is a regression from bug 1740989, but it's really uncovering a
regression from bug 1729342, sorta. Before that, we used to focus the
inner text field on rebuild via focusInnerTextBox().
One could argue that the focus fixup rule should really deal with this,
but I guess since content can't really unattach shadow DOM, it's less of
a general issue and more of an implementation detail.
The test uncovers another pre-existing issue (switching from date ->
test was also broken, and we left a bogus ElementState::FOCUS state in
the element).
Differential Revision: https://phabricator.services.mozilla.com/D158167
This change adds support for `content-visibilty: auto` as well as
showing and hiding content based on the relevancy of the content as
defined in the specification. Changes to relevancy are handled by
triggering updates in a set of `content-visibility: auto` frames stored
in PresShell at the appropriate time in the document lifecycle.
Some tests are now failing due to this feature exposing the failures,
but they will be fixed in later changes.
This change is a reland of an earlier version that properly updates
intrinsic sizes and triggers an update of remembered size for the
purposes of contain-intrinsic-size when content relevancy changes.
Co-authored-by: Jihye Hong <jihye@igalia.com>
Differential Revision: https://phabricator.services.mozilla.com/D159693
This change adds support for `content-visibilty: auto` as well as
showing and hiding content based on the relevancy of the content as
defined in the specification. Changes to relevancy are handled by
triggering updates in a set of `content-visibility: auto` frames stored
in PresShell at the appropriate time in the document lifecycle.
Some tests are now failing due to this feature exposing the failures,
but they will be fixed in later changes.
Co-authored-by: Jihye Hong <jihye@igalia.com>
Differential Revision: https://phabricator.services.mozilla.com/D159693
This doesn't change behavior, but clarifies a bit the naming to match
the scrollIntoView() API. Also makes the name generic (rather than
Top/Left/etc), since for scrollIntoView we want to make the axes be
logical.
That will be done in bug 1789464 (probably via an extra ScrollFlag).
Differential Revision: https://phabricator.services.mozilla.com/D162286
First, the test compares `document.querySelector(":active")` and a checkbox or
a radio button. However, Gecko activates ancestor elements too. Therefore,
Gecko returns `<html>` element or `null` for the selector. However, this is
an issue of CSS pseudo class compatibility which is **not** scope of the test.
Therefore, this patch makes it compare `document.querySelector("input:active")`
and a checkbox or a radio button instead.
Next, Gecko does not activate checkboxes and radio buttons when user presses
the space key, but the other browsers do it. Therefore, this patch makes
`HTMLInputElement::PostHandleEvent` do it and
`EventStateManager::PostHandleEvent` clear it at `keyup` of the space key.
Next, Gecko does not inactive active elements when it gets lost focus.
Therefore, this patch makes `nsFocusManager::NotifyFocusStateChange` do it
like the other browsers.
Finally, with manual testing of draft patches, I found some issues of
inactivating them when they are activated by `<label>`s. Therefore, I add new
tests in a separate file. Note that Chrome fails only in the cases testing
`<input type="radio">` with `<label>`.
Differential Revision: https://phabricator.services.mozilla.com/D160494
FlushAndCheckIfFocusable was returning false, when the real thing that's
going on is that the element _is_ focusable, but it's already focused.
Improve handling of FlushAndCheckIfFocusable elsewhere, though I don't
think that can change behavior since we get the delegated focus at that
point already. Still seems like the right thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D158935
The blur is a regression from bug 1740989, but it's really uncovering a
regression from bug 1729342, sorta. Before that, we used to focus the
inner text field on rebuild via focusInnerTextBox().
One could argue that the focus fixup rule should really deal with this,
but I guess since content can't really unattach shadow DOM, it's less of
a general issue and more of an implementation detail.
The test uncovers another pre-existing issue (switching from date ->
test was also broken, and we left a bogus ElementState::FOCUS state in
the element).
Differential Revision: https://phabricator.services.mozilla.com/D158167
This is callable from JS, and nothing guarantees that style has been
updated properly before. Without this, my previous patch causes failures
in browser/base/content/test/tabdialogs/browser_tabdialogbox_focus.js,
because the nsDeckFrame used to listen to attribute changes
synchronously and now it's style-based, so if you moveFocus right after
revealing it we'd end up with the wrong answer.
Differential Revision: https://phabricator.services.mozilla.com/D157886
