Replicated on Vector AND Minerva
- Click the omega character
- Click on the editing surface
This seems to disable the toolbar, and now I am unable to click anything in it (other than the 3 icons to the right in a separate menu).
No errors in console..
| Jdlrobson | |
| Nov 6 2018, 3:06 AM |
| F28500660: image.png | |
| Mar 28 2019, 7:59 PM |
| F27079974: issue2.gif | |
| Nov 6 2018, 3:43 PM |
| F27072569: issue.gif | |
| Nov 6 2018, 3:06 AM |
Replicated on Vector AND Minerva
This seems to disable the toolbar, and now I am unable to click anything in it (other than the 3 icons to the right in a separate menu).
No errors in console..
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Use nullSelectionOnBlur=false for ArticleTargets | mediawiki/extensions/VisualEditor | master | +9 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Esanders | T208826 Toolbar and toolbar dialogs (e.g. special characters tray) unexpectedly become disabled after clicking on page title | |||
| Resolved | Esanders | T219813 VE article editor should never have a NullSelection | |||
| Resolved | Esanders | T219829 De-activated selections should be visually distinct |
It looks like you clicked on the title which isn't part of the editing area, resulting in a null selection. When the selection is null the tools aren't available as there is nowhere to insert the characters.
I can reliably replicate this on desktop Minerva using the URL https://en.wikipedia.beta.wmflabs.org/wiki/Spain?useskin=minerva&action=edit if I click just under the edit toolbar. I can also replicate it on Vector just as regularly (new gif shows Vector):
Let me know if you need any further information.
I found this confusing as I hadn't realised what had happened. Thinking back about my goals I was probably trying to select a character or focus the editing area to start typing at the time.
The fact that there is a gap between the editing area and the toolbar seems a bit strange to me. Clicking where I clicked, I'd expect the focus to move to the start of the article and not disable the toolbar.
This situation led me to think I broke something and now I feel a bit stupid that I reloaded the entire page.
It seems like something should be done here to improve the user experience. I understand why it's happening now from a technical point of view, but still not from a user point of view.
@iamjessklein if you have any down time during next quarter to simply investigate this ticket please do so.
Yeah, I think it's uncontroversial that this is what would ideally happen. We came to the same conclusion in the triage meeting today when looking at this task (and before realizing you proposed this).
We recently made the heading selectable again. This means it wouldn't make sense to keep the tools available when you click on the heading.
I think it still would make sense. Heading is selectable but it's a "secret" feature with no UI feedback. There are also other non-selectable bits and pieces in that area (e.g. the site subtitle).
I think it still would make sense.
If you select the heading (collapsed or not) the document selection moves from the document to the heading. What exactly are we now proposing?
I just had a thought that we could probably deactivate the surface when that area is clicked. This preserves the surface selection (as a fake selection), so you can have a native selection elsewhere, and simultaneously the toolbar tools will still be enabled and work as expected.
I don't particularly like the idea of having two selections in the same plane, at least with inspectors or dialogs it is a bit clearer than the old selection is underneath the current one and so in some way inactive, but this could lead to genuine confusion about what happens next if I type:
A more radical approach could be to do away with the NullSelection entirely, and only ever deactivate surfaces, then make deactivated selections grey to indicate that the native cursor is not at that location. I think that other full document editors don't have the concept of a NullSelection *checks GoogleDocs* yup, they actually use a greyed-out selection I described.
Change 500741 had a related patch set uploaded (by Esanders; owner: Esanders):
[VisualEditor/VisualEditor@master] Make null-selection-on-blur optional
Change 500757 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Use nullSelectionOnBlur=false for ArticleTargets
https://gerrit.wikimedia.org/r/500741 unassigned from this task
Just https://gerrit.wikimedia.org/r/500757 to review
Change 500757 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Use nullSelectionOnBlur=false for ArticleTargets
@Esanders: Followed the steps of the original issue mentioned on the task, which seems fixed. But we seemed to fixed few more things as part of this, which is the selection on the editing surface will be grayed out if the heading is also selected, but it would be allowed to select both none the less? Is that correct?
However I noticed something that if you select heading first. and then try to select a text from the editing surface, it deselects the heading. That's also expected right?