Open Bug 1433262 Opened 3 years ago Updated 3 years ago

Focused element does not change if tab keydown event hides active element

Categories

(Core :: DOM: Events, defect, P2)

58 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: ewisuri, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce:

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Also occurs in Nightly 60.0a1 (2018-01-25)

Go to https://jsfiddle.net/hv83kr34/
Focus on first input
Press TAB


Actual results:

Focus is not moved to second input.


Expected results:

Focus moved to second input.

Adding a call to .offsetWidth after hiding the element fixes the problem, see: https://jsfiddle.net/hv83kr34/1/
Priority: -- → P2
I think the expected behavior is wrong - if a focused element is hidden the focus should be moved to the body, not to the next focusable element (https://github.com/w3c/web-platform-tests/blob/009111410a1099e85d4027a679985975757ceb4d/html/editing/focus/processing-model/focus-fixup-rule-one-no-dialogs.html#L36). That being said, that test currently fails in Firefox, since it keeps the focus to the hidden element.
I would expect moving focus to the body to be a last resort at preventing an invisible element having focus. In the case where the hiding occurs in the event handler for TAB keydown, I'd expect the default event behavior of shifting focus to the next focusable element would take precedence. For what it's worth, Chrome, IE and Edge all exhibit the expected behavior of shifting focus to the next visible element on TAB.
This behavior also applies if the focused element (when tab is pressed) is removed from the DOM. However a slightly more detailed example shows that FF is actually inconsistent in a strange way. Consider:
    <html><body>
        First: <input id='one'/> </br>
        Second: <input id='two'/> </br>
        Third: <input id='three'/> </br>
        Fourth: <input id='four'/> </br>
        <script>
            document.getElementById('two').addEventListener('keydown', () => {
                document.getElementById('body').removeChild(document.getElementById('two'))
            });
        </script>
    </body></html>

Scenario 1
    - Load page
    - Focus first input field
    - Press tab twice
    - On second tab press, the third input field becomes focused, which seems to be logical behavior
    - Summary: Tabbing out of second input field focuses the third input field

Scenario 2
    - Load page
    - Focus second input field
    - Press tab
    - First input field becomes focused
    - Summary: Tabbing out of second input field focuses the first input field
(In reply to Glen Reesor from comment #3)
> This behavior also applies if the focused element (when tab is pressed) is
> removed from the DOM. However a slightly more detailed example shows that FF
> is actually inconsistent in a strange way. Consider:
>     <html><body>
>         First: <input id='one'/> </br>
>         Second: <input id='two'/> </br>
>         Third: <input id='three'/> </br>
>         Fourth: <input id='four'/> </br>
>         <script>
>             document.getElementById('two').addEventListener('keydown', () =>
> {
>                
> document.getElementById('body').removeChild(document.getElementById('two'))
>             });
>         </script>
>     </body></html>
> 
> Scenario 1
>     - Load page
>     - Focus first input field
>     - Press tab twice
>     - On second tab press, the third input field becomes focused, which
> seems to be logical behavior
>     - Summary: Tabbing out of second input field focuses the third input
> field
> 
> Scenario 2
>     - Load page
>     - Focus second input field
>     - Press tab
>     - First input field becomes focused
>     - Summary: Tabbing out of second input field focuses the first input
> field

To clarify scenario 2 above -- focus the second input field by clicking (rather than tabbing). Thus, depending on how you got to the second input field (scenario 1 or scenario 2), tabbing out of it behaves differently.
You need to log in before you can comment on or make changes to this bug.