Navigator: move focus while navigating between screens

[ciampo]

In #36952 (comment), @mtias bring up the issue that the _ "back" links need the ability to focus the element they represent when you go back,_

I'm trying to summarise the questions that we need to answer here:

There's a few questions to be solved:

• Is focusing the exact link that "generated" the navigation necessary? Currently, a NavigatorScreen should already be able to move the focus on its own wrapper div when mounted.
• Should we look for a solution that can be applied directly to the Navigator component?
• What's the best way to store an ID for an element that gets removed for the DOM? (i.e. the "origin link" that we'd like to focus)\
• If we think that we'll need to start storing state in our Navigator component, should we re-consider adopting a third-party routing solution?

cc @diegohaz @youknowriad @mirka

[ciampo]

Personally, I'm not sure we'd need to restore the focus on the previous clicked link — focusing the whole "screen" should be enough (as it generally happen when going to the previous page in a browser via its standard history)

[youknowriad]

Personally, I'm not sure we'd need to restore the focus on the previous clicked link — focusing the whole "screen" should be enough (as it generally happen when going to the previous page in a browser via its standard history)

This should be the case already with the useFocusOnMount

[ciampo]

This should be the case already with the useFocusOnMount

Exactly, that's why I wrote:

Is focusing the exact link that "generated" the navigation necessary? Currently, a NavigatorScreen should already be able to move the focus on its own wrapper div when mounted.

I'm wondering if the current behaviour is not enough already

[mtias]

I see this behaviour for a list of Items comparable to toolbar items opening dropdowns — the expectation is when you close the dropdown the item that opened it is focused, not that it resets to the whole toolbar. Imagine the case with the list of blocks, which can be anywhere from 20+ to 100. You are making modifications to a blocks in sequence, but every time you go back it resets focus. It'd be pretty annoying.

[ciampo]

If we do need to implement this behaviour, it means that we need to start passing/storing state when a route changes (as explained also by @diegohaz here).

This potentially means that we'd need to keep a navigation history inside the internal Navigator state (together with an associated identifier of the element/component that caused that specific route navigation), so that when we we navigate "back" we have a reference of which element to focus.

On top of that, we'd need to understand what's the best format for that "identifier"

[mtias]

Or we could also think about it more broadly as cases where focus needs to be transferred because an interface session "ended". An interface can "end" by closing a popover, closing a modal, closing a sidebar, deleting a block, and also navigating back from a panel to its parent panel. That means perhaps the state we need to store is not at the Navigator level but at the general UI level.

[ciampo]

I've implemented a potential solution in a draft #37223. It still requires polishing, but it's definitely at a stage where we can judge if it's an approach that we want to implement or discard

[ciampo]

Closing as focus restoration was initially implemented in #38149 and later refined