[wp-trac] [WordPress Trac] #41900: Code Editor: Cursor jumps to end of file upon focus in the "contenteditable" inputStyle for CodeMirror in Additional CSS

WordPress Trac noreply at wordpress.org
Sun Sep 17 04:25:15 UTC 2017


#41900: Code Editor: Cursor jumps to end of file upon focus in the
"contenteditable" inputStyle for CodeMirror in Additional CSS
--------------------------+----------------------------
 Reporter:  westonruter   |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.9
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  accessibility
--------------------------+----------------------------
Description changed by westonruter:

Old description:

> In the editor which appears in the Customizer for the Additional CSS
> feature, when you click on the editor to focus and set the cursor on a
> given line, it will focus but then put the cursor at the end of the
> editor without scrolling to that position. Sometimes it will even add the
> active-line style to where you clicked, but the cursor is at the bottom.
> Every time you blur the editor an then focus back into the editor, the
> cursor will get moved to the end of the file.
>
> Of note, this issue can be observed exclusively in the editor for
> Additional CSS in the Customizer. It is not present on the theme/plugin
> editors. It is not even present for the code editor in the Custom HTML
> widget //in the Customizer// either. There seems to be something
> specifically about the Additional CSS editor.
>
> This issue appears when CodeMirror is configured with a 'contenteditable'
> `inputStyle`, which it is by default in core for the sake of a11y. Per
> the CodeMirror [https://codemirror.net/doc/manual.html#option_inputStyle
> docs] on `inputStyle`:
>
> > Selects the way CodeMirror handles input and focus. The core library
> defines the "textarea" and "contenteditable" input models. On mobile
> browsers, the default is "contenteditable". On desktop browsers, the
> default is "textarea". Support for IME and screen readers is better in
> the "contenteditable" model. The intention is to make it the default on
> modern desktop browsers in the future.
>
> If the `inputStyle` is changed from 'contenteditable' to 'textarea' then
> the issue goes away. This change:
>
> {{{#!diff
> --- src/wp-includes/general-template.php
> +++ src/wp-includes/general-template.php
> @@ -3142,7 +3142,7 @@ function wp_enqueue_code_editor( $args ) {
>                 'codemirror' => array(
>                         'indentUnit' => 4,
>                         'indentWithTabs' => true,
> -                       'inputStyle' => 'contenteditable',
> +                       'inputStyle' => 'textarea',
>                         'lineNumbers' => true,
>                         'lineWrapping' => true,
>                         'styleActiveLine' => true,
> }}}
>
> However, since the `inputSyle` of 'contenteditable' improves
> accessibility, I'm wary to make this change.
>
> Videos that depict the issue with the contenteditable inputStyle and how
> it is not present for the textarea inputStyle:
>
> FAIL: https://youtu.be/uSFJqf_zwFw
> PASS: https://youtu.be/CqMLObojkVU

New description:

 In the editor which appears in the Customizer for the Additional CSS
 feature, when you click on the editor to focus and set the cursor on a
 given line, it will focus but then put the cursor at the end of the editor
 without scrolling to that position. Sometimes it will even add the active-
 line style to where you clicked, but the cursor is at the bottom. Every
 time you blur the editor an then focus back into the editor, the cursor
 will get moved to the end of the file.

 Of note, this issue can be observed exclusively in the editor for
 Additional CSS in the Customizer. It is not present on the theme/plugin
 editors. It is not even present for the code editor in the Custom HTML
 widget //in the Customizer// either. There seems to be something
 specifically about the Additional CSS editor.

 This issue appears when CodeMirror is configured with a 'contenteditable'
 `inputStyle`, which it is by default in core for the sake of a11y. Per the
 CodeMirror [https://codemirror.net/doc/manual.html#option_inputStyle docs]
 on `inputStyle`:

 > Selects the way CodeMirror handles input and focus. The core library
 defines the "textarea" and "contenteditable" input models. On mobile
 browsers, the default is "contenteditable". On desktop browsers, the
 default is "textarea". Support for IME and screen readers is better in the
 "contenteditable" model. The intention is to make it the default on modern
 desktop browsers in the future.

 If the `inputStyle` is changed from 'contenteditable' to 'textarea' then
 the issue goes away. This change:

 {{{#!diff
 --- src/wp-includes/general-template.php
 +++ src/wp-includes/general-template.php
 @@ -3142,7 +3142,7 @@ function wp_enqueue_code_editor( $args ) {
                 'codemirror' => array(
                         'indentUnit' => 4,
                         'indentWithTabs' => true,
 -                       'inputStyle' => 'contenteditable',
 +                       'inputStyle' => 'textarea',
                         'lineNumbers' => true,
                         'lineWrapping' => true,
                         'styleActiveLine' => true,
 }}}

 However, since the `inputSyle` of 'contenteditable' improves
 accessibility, I'm wary to make this change.

 Videos that depict the issue with the contenteditable inputStyle and how
 it is not present for the textarea inputStyle:

 FAIL (inputStyle=contenteditable): https://youtu.be/uSFJqf_zwFw
 PASS (inputStyle=textarea): https://youtu.be/CqMLObojkVU

--

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


More information about the wp-trac mailing list