[wp-trac] [WordPress Trac] #42530: Unexpected focus lost when switching editor tabs

WordPress Trac noreply at wordpress.org
Tue Nov 14 10:18:11 UTC 2017


#42530: Unexpected focus lost when switching editor tabs
-------------------------------------+-------------------------------------
 Reporter:  ocean90                  |       Owner:  pento
     Type:  defect (bug)             |      Status:  reopened
 Priority:  normal                   |   Milestone:  4.9
Component:  Editor                   |     Version:  4.9
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch dev-reviewed   |     Focuses:  accessibility,
  commit                             |  administration
-------------------------------------+-------------------------------------
Changes (by afercia):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Replying to [comment:15 pento]:
 > The existing behaviour prior to 4.9 is:
 >
 > - When switching to the Text view, the `<textarea>` is not focussed.
 > - When switching to the Visual view, the editor is focussed, with the
 cursor placed at the start of the content.

 This is not entirely true. In 4.8.3 when switching to VIsual mode, the
 editor is ''not'' focused. In 4.7 it is. Worth noting this "auto focus" is
 a TinyMCE behavior, not something WordPress does. It was discussed at
 length because it's highly problematic for a11y, see for example #30490.
 I'd agree it should be discussed separately as it seems something changed
 in TinyMCE and the current behavior after [42176] matches the behavior in
 4.7. Will open a new ticket.

 However,

 I'm sorry but the current fix for the scrolling behavior doesn't seem a
 proper fix to me. Here's what happens for me, tested on 2 different
 machines and with different browsers: to reproduce

 - in the edit post Screen Options, enable all the metaboxes
 - uncheck "Enable full-height editor and distraction-free functionality."
 - edit a post that is long enough (it happens also with shorter posts but
 a longer one makes reproducing easier)

 In my case, the edited post is made of 1256 words:

 [[Image(https://cldup.com/Z0I204LjFN.jpg)]]

 Switch to Text mode:

 [[Image(https://cldup.com/S2YA4I_6Us.jpg)]]

 Select a word at the bottom of the post, then switch back to Visual mode:

 [[Image(https://cldup.com/oTTYBQhbKs.jpg)]]

 The editor page is now completely scrolled at the bottom, and the editor
 area is out of view. I guess this is not the best experience WordPress
 wants for users.

 Additionally, to keep the selection, some "placeholder" content gets
 inserted in the post. As a consequence, when switching mode, the
 `beforeunload` confirmation dialog to warn users there are unsaved changes
 kicks in even if the user hasn't made any change to the post content. To
 reproduce:

 - edit any post
 - switch the editor to Text mode
 - switch back to Visual mode
 - navigate away from the page
 - the confirmation dialog appears, warning there are unsaved changes

 [[Image(https://cldup.com/0cXJ_3Rctn.jpg)]]

 Of course, this would be very confusing for users since there were no
 intentional changes to the post content.

 Overall, I still think this new feature hasn't been tested enough and at
 this point of the release it should be just reverted. To recap:
 - the weird scrolling behaviors highlighted above significantly worsen the
 user experience
 - some bugs were discovered at the last minute, see also #42531 and there
 could be more. It just needs more testing, and I'd recommend to revert and
 postpone to 4.9.1
 - the code introduced for this feature doesn't meet the coding standards.
 Honestly, I'm a bit surprised to hear that the current standards are a
 minor concern because "eslint is coming soon". This is not a great
 argumentation. ESLint could be a thing in a few weeks, or in six months,
 or a year. In the meantime, any new code introduced in core should stick
 to the current coding standards.
 - the code introduced for this feature doesn't meet the ''documentation''
 standards.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42530#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list