Page MenuHomePhabricator

Toolbar and toolbar dialogs (e.g. special characters tray) unexpectedly become disabled after clicking on page title
Closed, ResolvedPublic

Description

Replicated on Vector AND Minerva

  1. Click the omega character
  2. 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..

issue.gif (682×1 px, 289 KB)

Event Timeline

Jdlrobson renamed this task from Toolbar breaks when I focus on editable content to Toolbar breaks when I focus on editable content after clicking omega character.Nov 6 2018, 3:06 AM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)

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):

issue2.gif (563×1 px, 1 MB)

Let me know if you need any further information.

I edited my comment, this looks like expected behaviour...

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.

cc @iamjessklein

JTannerWMF subscribed.

@iamjessklein if you have any down time during next quarter to simply investigate this ticket please do so.

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.

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).

We recently made the heading selectable again.

(For reference, that was T214790)

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.

(Jess said she had nothing to add right now)

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:

image.png (345×662 px, 85 KB)

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

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

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/500757

Esanders renamed this task from Toolbar breaks when I focus on editable content after clicking omega character to Toolbar and toolbar dialogs (e.g. special characters tray) unexpectedly become disabled after clicking on page title.Apr 6 2019, 5:06 PM

Change 500757 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Use nullSelectionOnBlur=false for ArticleTargets

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

@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?

Yes (see T219829) and yes :)

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?

Yes, those are reflected in the child tasks T219813 and T219829.

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?

Yes.

Yes (see T219829) and yes :)

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?

Yes, those are reflected in the child tasks T219813 and T219829.

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?

Yes.

cool! Marking it as verified then.