| Nemo_bis | |
| May 20 2016, 6:38 AM |
| F4041147: pasted_file | |
| May 22 2016, 9:15 AM |
| F4033554: talk-edit-popup.png | |
| May 20 2016, 6:38 AM |
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:
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.
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?
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"
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".
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):
Change 292029 had a related patch set uploaded (by Bartosz Dziewoński):
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions
Change 292029 merged by jenkins-bot:
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions
Change 292043 had a related patch set uploaded (by Jforrester):
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions
Change 292044 had a related patch set uploaded (by Jforrester):
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions
Change 292043 merged by jenkins-bot:
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions
Change 292044 merged by jenkins-bot:
ve.init.MWWelcomeDialog: Fix keyboard focus on dialog actions
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)
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".
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.
@Nemo_bis: Here's what I'm doing:
What should happen:
What happens:
@matmarex: when you click on the top 75% of the dialogue box, what happens to the initial focus on the bottom "button"?
The behaviour differs between Firefox, and Chromium:
@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…