Page MenuHomePhabricator

Visual Editor accesskey conflicts with Show Changes accesskey in edit page
Open, LowPublic


Pasted from

I make very heavy use of both the "Show preview" and "Show changes" edit buttons, or, more usually, their keyboard shortcuts: alt-shift-p and alt-shift-v.
Unfortunately, the latter shortcut has recently changed so that it now produces a pop-up asking me whether I want to use Visual Editor. I have no desire to use VE whatsoever (shudder), so this is extremely annoying - it is time-consuming and tedious to have to scroll all the way down to the edit box every time I want to preview the diff of my edit.
So can someone either change the shortcut for VE, or, failing that, provide a new shortcut for the "Show changes" button? If the latter, please remember to change the tooltip as well. Thank you.


Related Gerrit Patches:
mediawiki/extensions/VisualEditor : masterDesktopArticleTarget.init: Don't hardcode single-tab accesskey

Event Timeline

NSH002 created this task.Jan 24 2017, 3:34 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 24 2017, 3:34 PM
TheDJ renamed this task from Very annoying change in "Show changes" keyboard shortcut to Visual Editor accesskey conflicts with Show Changes accesskey in edit page.Jan 24 2017, 4:29 PM
TheDJ updated the task description. (Show Details)
Anomie added a subscriber: Anomie.Jan 25 2017, 2:46 AM

I've asked the editor to check his prefs (in both accounts). In some browsers, with some prefs settings, alt-shift-V is the standard keyboard for opening VisualEditor (in visual mode).

The access key for viewing changes is defined by the accesskey-diff message, and has been "v" in English since 2005 rMWf2cfcfdd9911: *html-safety fixes *made some things localizable or better localizable.

I see two places in VisualEditor that try to create an element with the same accesskey.

In other words, it seems VE hijacked the shortcut key that core had been using for a long time.

In Firefox 50.1.0 and this edit page,

  • With my usual account and the preference set to show only a single tab, it hits the second bit of VE code. The effect of this duplication is that Alt+Shift+V focuses the button but does not submit the form.
  • If I change my preference to show two edit tabs, it presumably hits the first bit of VE code instead. Pressing Alt+Shift+V switches the focus between the button and the "ve" tab.
  • As an anon after clicking "Start editing" at the popup it appears to be doing the same as the first bullet.

I can't reproduce the behavior of popping up asking if I want to use VE. It doesn't seem to matter whether I use Monobook or Vector. Behavior may of course differ in different browsers.

The editor has VisualEditor disabled (visualeditor-preference-betatempdisable is checked) in both accounts. I assume therefore that VisualEditor's keyboard shortcut should never be available.

I assume that the pop-up is the "Do you want to switch to visual editing?" pop-up, which appears when you have started editing a section in a wikitext editor and are trying to switch to the visual editor.

Change 337610 had a related patch set uploaded (by DLynch):
DesktopArticleTarget.init: Don't hardcode single-tab accesskey

DLynch added a subscriber: DLynch.Feb 14 2017, 6:05 PM

^^^ Patch is just to stop the hardcoded v which was pointed out, rather than any actual resolution of the issue.

Change 337610 merged by jenkins-bot:
DesktopArticleTarget.init: Don't hardcode single-tab accesskey

Jdforrester-WMF triaged this task as Low priority.May 25 2017, 2:25 PM

The problem now is that both shortcuts have now been established for many years, which wasn't a problem when edit source and VE were always on separate pages. We can either change the VE shortcut and potentially annoy a bunch of VE users, or maintain the status quo of it behaving differently depending on context.

or maintain the status quo of it behaving differently depending on context.

Behaving differently depending on context wouldn't be a problem, assuming the context is clear to the user. This bug is about it not functioning at all due to the collision.

TheDJ added a comment.EditedJun 21 2017, 2:40 PM

BTW. it conflicts in two contexts. The history page was also using the 'v' accesskey for the "compare selected revisions". Fewer people know about that one and probably I was the only one who ever complained about that conflict, but it is still a conflict.

Oh look, i wasn't the only one to complain about that: T54969: accesskey "v" is already used for "show changes" and T54701: Alt+Shift+V access key in the wikitext editor switches to the visual one, so conflicts with 'show changes' which no longer works in Chrome, focus splits in Firefox

...or maintain the status quo of it behaving differently depending on context.

I don't mind it behaving differently depending on context (depending on the details, etc.).

But it doesn't seem to behave at all in some browsers right now. If we roughly rank the available options from best to worst, "Do nothing at all in Firefox, but switch to visual mode in Chrome and Safari when the 2017WE is not enabled and Show Changes when it is" (which is what the comments at T167832 indicate that we've got, at least on a Mac) is very low on my list of desirable outcomes. Could we please make it "Always do X, no matter what browser or OS you're using"?

Deskana moved this task from To Triage to Freezer on the VisualEditor board.Jul 14 2017, 10:31 AM

I don't think it makes sense to have different actions depending on browser, either.

Also, I don't see why it should load the visual editor if the 2017 wikitext editor is not enabled. I would expect it to also show the changes when using the classic editor.

There is a third extension fighting for 'v' accesskey on edit page: FlaggedRevs.

Initially set as accesskey-ca-current key message on 2008-07-14 (d9b78482), and to the json files on the migration (f3e05ee39). r37646 makes it look like it was previously hardcoded, but I didn't find how it is used…

For ab example, see this page.