Page MenuHomePhabricator

"Jump to navigation" unexpectedly included in clipboards
Open, Needs TriagePublic

Description

  1. Open https://www.wikidata.org/wiki/Q2560289.
  2. Select the top text "Dutch bank", by moving cursor to left of this text, holding down mouse, and dragging to the right.
  3. Copy to clipboard and paste somewhere.

Actual result:

Jump to navigation
Jump to search
Dutch bank

capture.png (764×1 px, 114 KB)

I know these elements are visually hidden and in the original DOM at the top of the page, which explains how they get included.

What is especially surprising is that they end up selected even if you minimally and carefully select the words in question. It's not only included when you start dragging from e.g. a line above which might explain why the invisible block gets included. That's not the case.

In any event, perhaps this would be a good use case for user-select: none; - assuming that when these links are used via assistive technology and/or keyboard tab navigation, that these button labels don't need to be selectable text (similar to form buttons, which are generally not selectable as textx either).

Alternatively, if we want to make them selectable as text if and only if the links are focussed, we could do that with a :not() rule, similar to how the current visibility is set up in CSS.

Event Timeline

Jdlrobson added a subscriber: Jdlrobson.

@Volker_E is there any reason mixin-screen-reader-textdoes not apply user-select: none? Both skins are using that mixin so it would make sense to fix this generally.

Jdlrobson edited projects, added MonoBook (Tracking); removed MonoBook.

@Jdlrobson Not that I know of. Could possibly see side-effects in some cases, for example I don't know about selecting in assistive technology.
Would therefore rather put the user-select none mixin on those two links.

Also first time seeing this task.

Maybe a new mixin mixin-screen-reader-text-unselectable ?

Why not combining where needed? -> less maintenance overhead

Why not combine where needed? -> less maintenance overhead

Suggested this as a short-term solution, because you weren't sure about side effects.

I'd like to avoid random CSS accumulating, particularly in lesser maintained skins like Monobook. Both skins are using mixin-screen-reader-text so I'd rather fix that mixin to handle this appropriately.

But do you know with every assistive technology out there how users are going about the text that was read out to them and the users would like to copy?
I wouldn't mix this in for unwanted side-effects as said above.

I was also mislead by .oo-ui-unselectable() mixin in my memory. Thought we have the same in mediawiki.mixins.

Understood. All I'm saying is if we are adding user-selectable: none for the purpose of not making screen reader text copy/pastable we should have a dedicated well-named mixin in core to document that rather than adding user-select: none everywhere on a case by case basis.

Perhaps a parameter on the existing mixin would be appropriate if we don't want a new one?

Change 770103 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] mediawiki.mixins: Add `.user-select()` mixin

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

Change 770103 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.mixins: Add `.user-select()` mixin

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

Volker - would you be able to submit the appropriate patch for Vector?