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.
|mediawiki/extensions/VisualEditor : master||DesktopArticleTarget.init: Don't hardcode single-tab accesskey|
- Mentioned In
- T156176: At least 5 accesskeys don't work in Chrome on Windows as suggested by tooltip
- Mentioned Here
- rEFLRd9b784824b85: * Add accesskeys (bug 14783) * Remove some hardcoding
rEFLRf3e05ee3963b: Migrate to JSON i18n
T167832: The same keyboard shortcut cannot simultaneously be 'Show changes' and 'Switch to the visual editor'
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
T54969: accesskey "v" is already used for "show changes"
rMWf2cfcfdd9911: *html-safety fixes *made some things localizable or better localizable
rEVED3c55bfbb808e: Add a hidden link with accesskey=v in SET prefer-wt mode and remember-last…
rEVEDdb447733b0dd: Fix logic for create accesskey=v, and bind to onEditTabClick
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.
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
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"?
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.