Don't move focus to the editor when switching editor mode

[afercia]

Splitting this out from #42530.

When switching the classic editor from "Text" mode to "Visual" mode, the editor area is focused. Worth noting this is a TinyMCE behavior, not something WordPress does. For a number of years it always worked this way, with a few exceptions. For example, in 4.8.3 the editor is not focused for me, not sure if something changed in TinyMCE.

Regardless of what happened to TinyMCE, I'd propose to finally discuss this behavior and evaluate if it's a good one for all users. It was discussed sometimes in the past, as part of other issues, see for example #30490 but never fully addressed.

This issue is even more relevant now that #41962 is going to move focus to the editor in both Visual and Text mode, when there is a selection.

Moving focus programmatically is often problematic because it generally assumes just one, specific, workflow.

From an usability perspective, moving focus to the editor assumes users want to start typing immediately. This may or may not be true. It's an assumption.

From an accessibility perspective, unexpectedly switching context is a huge concern. See also the discussion on #42530.

Any thoughts and discussione welcome!

[afercia]

The 5.1 release beta 1 is today. Punting to Future Release.

Previously, switching between Visual and Text mode would unconditionally move focus into the destination editor (via editor.focus() / textArea.focus()), because the selection-bookmark mechanism used to preserve cursor position across the switch is populated almost every time, regardless of whether the source field was actually focused.

In the common case — clicking the Visual/Text tab — focus has already moved to that tab button by the time the switch handler runs, so forcibly focusing the editor content area pulls focus away from the control the user just activated. This is disruptive for keyboard and assistive technology users, who lose their place in the document unexpectedly.

Now, focus is only moved into the destination editor if the source field already had focus when the switch was triggered (e.g. a keyboard shortcut fired while actively editing). The cursor/selection position is still restored either way, so it's correct if the user does click into the field afterward — only the automatic focus-stealing (and the accompanying scroll-into-view, which would otherwise move the page without moving focus) is skipped.

Trac ticket: https://core.trac.wordpress.org/ticket/42540
## Use of AI Tools

AI assistance: Yes
Tool(s): Claude
Model(s): Opus 4.7
Used for: Initial code skeleton; final implementation was reviewed and tested by me.