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.

• This code uses the message accesskey-ca-ve-edit which has only been set since 2013 375a7fceff.
• This code just unconditionally uses 'v'. I note the conditional guarding the second bit of code was recently changed in rEVEDdb447733b0dd: Fix logic for create accesskey=v, and bind to onEditTabClick and was only added in 2016 rEVED3c55bfbb808e: Add a hidden link with accesskey=v in SET prefer-wt mode and remember-last….

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

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

^^^ 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

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

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.

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

In T156141#3365753, @Esanders wrote:

...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"?

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.

@AhmadF.Cheema reports problems with this in detail at https://www.mediawiki.org/wiki/Topic:Veyo7xqvss4jz8d8