Page MenuHomePhabricator

Inaccessible drop-down menu in Visual Editor for New Vector users
Closed, ResolvedPublic

Description

Now that the search box was moved to the right side of the logo in the New Vector skin, the Twinkle tab has now become the rightmost item among the tabs above the page. The new change has also revealed an important issue, which affects users when the Visual Editor is used. When you are on the editing screen (?veaction=edit), you immediately notice that the [Publish changes...] button disallows access to the contents of the TW drop-down. Other items that might be there such as the [Page] & [User] tabs introduced by [[m:MoreMenu]] are fine. The default [More] tab, on the other hand, is fine for me at enwiki but not for other users I've talked to, while its equivalent [Daha] is curiously suffering from the same problem for me at trwiki.

Behavior

  1. Disable Legacy Vector skin by unselecting this option at English Wikipedia.
  2. Enable Twinkle from the gadget list.
  3. Click on the random article link.
  4. Click Edit on the randomly opened article page. Make sure the Visual Editor is enabled so that you would see a VE screen as a result.

Actual

  1. ❗️Hover over the TW dropdown at the top of the page. You should see that it appears behind the [Publish Changes] button, thereby becoming inaccessible:
Notice the Publish changes button appears atop Twinkle's dropdown
Screen Shot 2020-10-13 at 8.54.07 AM.png (700×944 px, 95 KB)

Expected

  1. ✅Hover over the TW dropdown at the top of the page. You should see that it appears in full without being obfuscated by any other part of the page.

See this as further confirmation. For me the [More] dropdown is accessible at enwiki, but not at trwiki.

Event Timeline

Let me elaborate on the steps to reproduce the problem.

  1. Disable Legacy Vector skin by unselecting this option at English Wikipedia.
  2. Enable Twinkle from the gadget list.
  3. Click on the random article link.
  4. Click Edit on the randomly opened article page. Make sure the Visual Editor is enabled so that you would see a VE screen as a result.
  5. Hover over the TW dropdown at the top of the page. You should see that it appears behind the [Publish Changes] button, thereby becoming inaccessible.

See this as further confirmation. For me the [More] dropdown is accessible at enwiki, but not at trwiki.

Let me elaborate on the steps to reproduce the problem...

The way you've written these reproduction steps is quite helpful – thank you, @Vito-Genovese. I've added them to the task description.

@ppelberg shared this is a Medium priority task @ovasileva

Jdlrobson added a subscriber: Jdlrobson.

This was broken by our DOM order changes. A rule .ve-activated #content { position: relative;} establishes a z-index for the editing area in old Vector. In new Vector this is wrapped in another element. Both #mw-content-container and #mv-navigation will need to be position relative and establish a z-index. Should probably be done inside VisualEditor extension.

This was broken by our DOM order changes. A rule .ve-activated #content { position: relative;} establishes a z-index for the editing area in old Vector.

It actually doesn't establish a stacking context (I assume that's what you mean), you'd need some additional properties to do that (https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context). But this was broken by the DOM order changes.

It worked correctly previously because VisualEditor toolbar and Vector dropdown menu both had the same z-index of 2, and they were in the same stacking context, and the dropdown menu came after the toolbar in the DOM – so the menu appeared over the toolbar. Now the dropdown menu comes before the toolbar in the DOM – so the menu appears under the toolbar.

Old VectorNew Vector
image.png (2×3 px, 1 MB)
image.png (2×3 px, 1 MB)
image.png (2×3 px, 1 MB)
image.png (2×3 px, 1 MB)

The simplest way to fix this would be to change one of the z-indexes, so that the behavior doesn't depend on the DOM order. We can't lower the z-index of the VisualEditor toolbar, because z-index 1 is used for editing surface elements like context menus, which should appear under the toolbar. Perhaps we can raise the z-index of the Vector dropdown menu instead.

Both #mw-content-container and #mv-navigation will need to be position relative and establish a z-index. Should probably be done inside VisualEditor extension.

This may be a better fix in the long term, but right now it will cause the same issue as T264679 to occur with the normal VisualEditor interface (I just tried it), so this approach will have to wait until we resolve that task.

image.png (2×3 px, 703 KB)

Change 636736 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/Vector@master] Declare z-index of newly ordered DOM

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

I think given the DOM order change, it does made sense for Vector to update its z-indexes per my patch Now the menus are ordered before the content area, they need to visibly be one above the content area for z-index. Can you confirm that would fix this issue (once fix for T264679 has landed) ?

It does, but it also causes the footer issue. That seems worse than fixing it without causing new issues.

Change 636736 abandoned by Jdlrobson:
[mediawiki/skins/Vector@master] Declare z-index of newly ordered DOM

Reason:

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

Would it be possible to merge the Vector patch you proposed in October?

Change 636736 restored by Jdlrobson:
[mediawiki/skins/Vector@master] Declare z-index of newly ordered DOM

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

Change 636736 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Fix z-index of navigation menus

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

That should resolve the issue. Note sure where it should go on your workboard now, so I'll move it here to make sure it gets looked at.

ppelberg claimed this task.