Turbo Streams: Manage element focus

[seanpdoyle]

When a <turbo-stream> modifies the document, it has the potential to
affect which element has focus.

For example, consider an element with an [id] that has focus:

<label for="an-input">
<input id="an-input" value="an invalid value"> <!-- this element has focus -->

Next, consider a <turbo-stream> element to replace it:

<turbo-stream action="replace" target="an-input">
  <template>
    <input id="an-input" value="an invalid value" class="invalid-input">
  </template>
</turbo-stream>

Prior to this commit, rendering that <turbo-stream> would remove the
element with focus, and never restore it.

After this commit, the Session will capture the [id] value of the
element with focus (if there is any), then "restore" focus to an element
in the document with a matching [id] attribute after the render.

Similarly, consider a <turbo-stream> that appends an element with
[autofocus]:

<turbo-stream action="append" targets="body">
  <template>
    <input autofocus>
  </template>
</turbo-stream>

Prior to this commit, inserting an [autofocus] into the document with
a <turbo-stream> had no effect.

After this commit, the Session will scan any <turbo-stream> elements
its about to render, extracting the first focusable element that
declares an [autofocus] attribute.

Once the rendering is complete, it will attempt to autofocus that
element. Several scenarios will prevent that, including:

• there aren't any [autofocus] elements in the collection of
  <turbo-stream> elements
• the [autofocus] element does not exist in the document after the
  rendering is complete
• the document already has an element with focus

[seanpdoyle]

@kevinmcconnell if you're available, this is ready for review.

[seanpdoyle]

@manuelpuyol @marcoroth if you're available and interested in this feature, I'd really appreciate some review!

[marcoroth]

+1 from me for this change.

The only thing to consider, which I think is currently not supported, is something like.

<input class="input" value="a value"> <!-- this element has focus -->

and a Turbo Stream like:

<turbo-stream action="replace" targets=".input">
  <template>
    <input class="input" value="a new value">
  </template>
</turbo-stream>

Unless I'm missing something.

[seanpdoyle]

+1 from me for this change.

The only thing to consider, which I think is currently not supported, is something like.

<input class="input" value="a value"> <!-- this element has focus -->

and a Turbo Stream like:

<turbo-stream action="replace" targets=".input">

  <template>

    <input class="input" value="a new value">

  </template>

</turbo-stream>

Unless I'm missing something.

I think this accounts for that with the timestamp [id] generation, marking, and teardown.

[seanpdoyle]

Re-reading the code, those time stamps only mark autofocus elements. Without some kind of css path matching, tracking focus across anonymous elements isn't supported.

[marcoroth]

Doesn't the timestamp generation just account for the case in Turbo Streams where you have the autofocus attribute?

[marcoroth]

Re-reading the code, those time stamps only mark autofocus elements. Without some kind of css path matching, tracking focus across anonymous elements isn't supported.

Okay yeah, that makes sense. I guess it's fine to have the requirement for an id attribute to be present.

[seanpdoyle]

Okay yeah, that makes sense. I guess it's fine to have the requirement for an id attribute to be present.

👍

Just to clarify, tracking focus for anonymous elements isn't currently supported either.

[brunoprietog]

Hi, why are you making this exception?

the document already has an element with focus

I imagine a case like the following. A user presses a button, and the focus stays on that button. In that case, as the document has a focused element, the autofocus attribute of the element coming from the Turbo stream would not be respected. Is this the case?

In my opinion, if there is an autofocus attribute, it should be focused even if another element has the current focus.

[seanpdoyle]

@afcapel @kevinmcconnell I've rebased this changeset to account for the migration from TypeScript. It's ready for re-review.

[afcapel]

Nice one, thanks @seanpdoyle 🙏

[michelson]

Hi @seanpdoyle could happen that the processing of new messages is blocked by this addition?
I'm I diving into the code because we have found an issue when receiving stream messages on tabs that are not visible/inactive, please see this issue:

hotwired/turbo-rails#338

pd: I've replaced all the nextAnimationFrame functions for nextMicroTask() and it works!