Page MenuHomePhabricator

"Start editing" popup can't be dismissed without clicking "Start editing"
Closed, ResolvedPublic1 Story Points

Description

When the "start editing" popup/splashscreen interrupts me (T135682), the only way to close it (other than closing the tab) seems to be a click of the "Start editing" link:


Not only I feel blackmailed by such an interface ("click here to admit that you're a newbie, or go away"), but I may not be able to click. At a minimum, the splashscreen needs an X button and the ability to get out with Esc. Clicking outside the popup doesn't dismiss it either, currently.

Event Timeline

Nemo_bis created this task.May 20 2016, 6:38 AM
Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptMay 20 2016, 6:38 AM
Nemo_bis updated the task description. (Show Details)May 20 2016, 6:50 AM
Nemo_bis updated the task description. (Show Details)May 20 2016, 8:53 AM

I may not be able to click

Why?

This issue is not specific to the welcome dialog, I think it applies to all OOjs UI dialogs.

From the screenshot, it looks like the dialog is distorted (the icon overlaps the text paragraph; monobook related?). I guess maybe something else is overlapping the button on the bottom as well, making click events go somewhere other than the button?

When first confronted by this, I thought "Ah, a welcome message for an editor with seven years experience and more than 146,000 edits (not to mention being an admin since 2011) - this just has to be them trying to get me to change my methods". So I got the immediate impression that if I clicked "Start editing", I would be forcibly switched to VE (something I had opted out of as soon as it became possible to), and that there was no way of continuing with the proper Wikitext editor. So it needs an obvious dismiss link, or an X at top right, something that makes it clear that you can continue as you were.

Pipetricker added a subscriber: Pipetricker.EditedMay 21 2016, 8:48 AM

At WP:VPT#Why am I seeing a "Welcome" message?, Whatamidoing (WMF) mentioned: "One of the devs also suggested making it possible to dismiss things like this by clicking anywhere outside the box".

That would make it too easy to dismiss unintentionally. It can be very frustrating when you dismiss a message instinctively or by slip of the mouse without really reading it and have no way to get it back, not knowing if it was important or not.

I can't think of any scenario where you have a working mouse and would not be able to click the button. Enlighten me.

Assuming you can't use the mouse, the dialog can already be dismissed by pressing Escape on your keyboard. When all else fails, the button is keyboard-accessible and can be tabbed to and triggered by pressing Enter.

The Escape key certainly does not dismiss the dialog, at least not in Firefox 46 with MonoBook.

By "the button", I assume that you mean the "Start editing" link. It's not clear that it is a button - it has the same background, no distinct border except at the top, which gives it all the appearance of the bottom row of a two- or three-row table. It's also not clear that all it does is remove the popup - the impression given is that something else will happen - perhaps the VE will be launched, perhaps you'll be taken to a tutorial on editing.

Looks like the dialog isn't getting the selection, so escape keys are being sent to the handler.

I can't think of any scenario where you have a working mouse and would not be able to click the button. Enlighten me.

What makes you suppose the user has a working mouse?

NickK added a subscriber: NickK.May 21 2016, 7:51 PM

As I have already written in T133800, there is strictly no key that can close this dialog, and it is annoying to have to click on a pop-up each time. It is just necessarily to add a key to dismiss this dialog, the most obvious choice being "Esc"

TheDJ added a subscriber: TheDJ.EditedMay 21 2016, 11:09 PM

I can confirm that if I manually move the focus to the button, that the escape key does work (the same as it does on other OOjs UI dialogs).

The debugger shows that after the window opens that <body> has the initial focus (document.activeElement), which is the default. So something is going wrong in the setup indeed.

This is an accessibility problem.

How do you "manually move the focus to the button"? Tabbing does nothing; hovering over the box (it is not visually styled as a button, so it is not a button but a link with a large hot-spot) changes the mouse pointer to a pointed finger; so it can't be clicked in without actioning the blue "Start editing" link, which, with the presence of the black text "Switch to the visual editor" on the row immediately above, gives the impression that VE will be launched.

There are no tooltips; and nothing showing at the bottom of the screen to indicate what URL is about to be reached. Right-click does not offer "Copy Link Location".

I can't think of any scenario where you have a working mouse and would not be able to click the button. Enlighten me.

What makes you suppose the user has a working mouse?

By god, nothing at all, which is why the second part of my comment, the one you neglected to quote and apparently also read, explained the keyboard accessibility features which normally work in OOjs UI dialogs.

This has to be an issue specific to this dialog. In various OOjs UI dialogs used elsewhere the Escape key works just fine to close them (I just tested: the demo page, the upload dialog in wikitext editor, license preview dialog in UploadWizard, some other dialogs in VisualEditor).

I see why this is happening now. A fix should be simple.

A good way to debug this kind of issues is to add any event handler on 'focus' and 'blur' events globally (e.g. $('body').on('focusout', $.noop).on('focusin', $.noop)), then enable "Event Listener Breakpoints" on focus and blur. (These instructions and screenshot are from Chrome's debugger, I think Firefox and Edge offer something similar.)


As the dialog is opening, OOjs UI places keyboard focus first on the window itself (OO.ui.Window.prototype.ready), then on the "Start editing" button (OO.ui.MessageDialog.prototype.getReadyProcess). This is what normally allows for the keyboard accessibility. But in this specific case, the welcome dialog calls setMode() afterwards (mw.libs.ve.WelcomeDialog.prototype.getReadyProcess), which has the side-effect of calling detachActions() (OO.ui.Dialog.prototype.onActionsChange), which loses the focus.

The fix (leaving it to someone from the VE team to implement):

  • As a quick fix that could be easily backported and deployed, mw.libs.ve.WelcomeDialog.prototype.getReadyProcess() should manually focus one of the actions after calling setMode().
  • In the long term, we should fix OO.ui.Dialog.prototype.onActionsChange to avoid losing the focus (either don't detach everything, or remember what was focussed and restore it afterwards).
Krinkle removed a subscriber: Krinkle.May 23 2016, 8:05 PM

Change 292029 had a related patch set uploaded (by Bartosz Dziewoński):
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions

https://gerrit.wikimedia.org/r/292029

matmarex claimed this task.May 31 2016, 9:18 PM

Change 292029 merged by jenkins-bot:
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions

https://gerrit.wikimedia.org/r/292029

Change 292043 had a related patch set uploaded (by Jforrester):
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions

https://gerrit.wikimedia.org/r/292043

Change 292044 had a related patch set uploaded (by Jforrester):
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions

https://gerrit.wikimedia.org/r/292044

Jdforrester-WMF closed this task as Resolved.May 31 2016, 10:21 PM
Jdforrester-WMF triaged this task as High priority.
Jdforrester-WMF removed a project: Patch-For-Review.
Jdforrester-WMF set the point value for this task to 1.

Change 292043 merged by jenkins-bot:
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions

https://gerrit.wikimedia.org/r/292043

Change 292044 merged by jenkins-bot:
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions

https://gerrit.wikimedia.org/r/292044

Mentioned in SAL [2016-05-31T23:43:53Z] <dereckson@tin> Synchronized php-1.28.0-wmf.4/extensions/VisualEditor/modules/ve-mw/init/ve.init.MWWelcomeDialog.js: ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions (T135808) (duration: 00m 23s)

Mentioned in SAL [2016-05-31T23:45:26Z] <dereckson@tin> Synchronized php-1.28.0-wmf.3/extensions/VisualEditor/modules/ve-mw/init/ve.init.MWWelcomeDialog.js: ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions (T135808) (duration: 00m 22s)

sladen added a comment.EditedJun 5 2016, 10:43 AM

The difference appears to be that "Start editing" is now highlighted (and focused) by default.

However, per the title of the bug: it is still the case that the popup can't be dismissed without clicking "Start editing".

However, per the title of the bug: it is still the case that the popup can't be dismissed without clicking "Start editing".

For most of the users that's true, but a minuscule minority will now be able to use the Esc button. A (X) somewhere would definitely help.

sladen added a comment.EditedJun 5 2016, 11:25 AM

@Nemo_bis: Here's what I'm doing:

  1. https://en.wikipedia.org/wiki/x?action=edit
  2. Click anywhere on the "Welcome to Wikipedia box" (top ~75% of the popup)
  3. Press Escape

What should happen:

  • Popup should close

What happens:

  • Nothing

@sladen The popup closes for me when I do that.

sladen added a comment.Jun 6 2016, 3:49 PM

@matmarex: when you click on the top 75% of the dialogue box, what happens to the initial focus on the bottom "button"?

sladen added a comment.Jun 6 2016, 3:54 PM

The behaviour differs between Firefox, and Chromium:

  • Firefox:, buttons are above one another; focus disappears; escape ignored
  • Chromium:, buttons resize to be side-by-side; focus disappears; escape processed.

@sladen The button loses focus, but that does not prevent Escape from working.

Ehh, yeah, in Firefox it's broken.

@sladen I filed a separate task T137134 about this, since it's not specific to this particular dialog (and also T137126 and T137130 for other bugs I noticed when investigating). I don't think it is a high priority issue, since keyboard navigation now works until you click inside the dialog, and if you clicked the dialog, you can just click the button too…