[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:24:36 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:
> https://cloudup.com/iVxXkAMI1XR
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: https://youtu.be/uSFJqf_zwFw
PASS: https://youtu.be/CqMLObojkVU
--
--
Ticket URL: <https://core.trac.wordpress.org/ticket/41900#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list