Topic on VisualEditor/Feedback

Tracked in Phabricator
Task T106419

Issue

In the save page dialog, when I try to click the Summary input field, the field immediately loses focus. Instead, focus is put on the article text in the background (I can type there while the dialog is open).

Steps to reproduce:

• Open any page and make a change through the VisualEditor.
• Hit save button -> popup opens
• Click the summary input text field

Specs

• Chrome: 43.0.2357.81 m
• Platform: Windows 8.1 Pro
• MediaWiki: 1.25.1
• Skin: Vector

Currently experiencing the same issue, has anyone found a fix for this?

Found a temporary fix for the time being: when the save dialog comes up, open up the developer tools in your browser and go to the Console (F12 -> Console in Google Chrome) and enter "document.querySelector('input').focus()"

Once you click on the text box again, it'll be in focus. Wonder if we can get a permanent fix/solution anytime soon, because this is a pretty big inconvenience right now.

Note: Possibly Windows only? I cannot reproduce this, on Ubuntu, using Chromium 37 or Firefox 38, at my sandbox on this wiki.

Note2: Whilst the summary box is open, the only way I can get my cursor to focus on the document behind, is to use the [Tab] key.

Debian\Ubuntu, MediaWiki 1.25.1, Visual Editor REL1_25, Vector skin REL1_25 Safari, IE, Google Chrome - the same issue :\

This bug really hurts the usability of VisualEditor. I'm about to deploy it in our corporate wiki, but I'm hesitant because I know I'll have an unending stream of user complaints.

Things like this should be on the top of the list to fix!

This issue is tracked at Phab:T106419. Thanks for the feedback.

A hacky patch:

--- extensions/VisualEditor/modules/ve-mw/ui/dialogs/ve.ui.MWSaveDialog.js.old	2015-09-02 09:51:37.435374937 +0900
+++ extensions/VisualEditor/modules/ve-mw/ui/dialogs/ve.ui.MWSaveDialog.js	2015-09-02 09:46:50.733371937 +0900
@@ -480,6 +480,7 @@
 					)
 				);
 			} );
+                        this.editSummaryInput.focus();
 		}, this );
 };

All it does is add a focus to the end of the getSetupProcess function call identical to the call in getReadyProcess, which seems to fix it with both recent chrome and firefox on windows and linux. It doesn't seem to be the correct solution, but it makes it work for now without any obvious problems.