Last modified: 2011-05-24 08:59:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 28945 - Keyboard shortcuts on history page no longer work in 1.18
Keyboard shortcuts on history page no longer work in 1.18
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
1.18.x
All All
: High normal (vote)
: ---
Assigned To: Brion Vibber
: code-update-regression
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-12 07:48 UTC by Michael M.
Modified: 2011-05-24 08:59 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Michael M. 2011-05-12 07:48:48 UTC
Before the "Compare these two versions" button was replaced via JavaScript with a link there were two keyboard shortcuts, which now no longer work:

* Pressing [Alt] + [Shift] (browser dependend) + [v]
* Pressing Enter

Both used to submit the form and so compare the two selected versions.
While the first just doesn't work, pressing enter sometimes now triggers revisiondelete unwantedly.
Comment 1 Mark A. Hershberger 2011-05-12 22:24:53 UTC
marking this as a 1.17 blocker.  Could you check that version?  http://www.mediawiki.org/wiki/MediaWiki_1.17
Comment 2 Brion Vibber 2011-05-13 10:49:34 UTC
This'll be from the recent code to replace the buttons with clickable links, and I don't believe it's in 1.17.

The JS code that replaces the button probably needs to copy the accesskey from the button to the link.
Comment 3 Brion Vibber 2011-05-14 09:27:55 UTC
Done in r88035.
Comment 4 Michael M. 2011-05-21 07:29:14 UTC
This fixes the accesskey issue but not the problem with enter key.

After some test I must be a bit more precise:
Submitting the form on enter key is a Firefox/Internet Explorer specific behavior, Opera and Konqueror do nothing when the radio buttons have the focus and you press enter. Adding an explicit event handler for keydown (or keypress or keyup) for the radio buttons should solve this.
Comment 5 Mark A. Hershberger 2011-05-23 01:44:48 UTC
> Submitting the form on enter key is a Firefox/Internet Explorer
> specific behavior, Opera and Konqueror do nothing when the radio
> buttons have the focus and you press enter. Adding an explicit event
> handler for keydown (or keypress or keyup) for the radio buttons
> should solve this.

This is an upstream bug or feature then, right?

Sounds like that bit is WONTFIX or, more precisely, outside the scope
of something MW should fix.  People hate it when you change the
behavior of their browser.
Comment 6 Derk-Jan Hartman 2011-05-23 06:28:13 UTC
Can I just ask what the point is in replacing a button with a javascript button, if it breaks the earlier form behavior ?
Comment 7 Michael M. 2011-05-24 08:59:59 UTC
(In reply to comment #5)

> People hate it when you change the
> behavior of their browser.

Replacing the submit button with a link does change the behavior for most (= all Firefox and Internet Explorer) users. One can't really expect a browser to detect that pressing the enter key should be treated as a click on the link the submit button was replaced with, so it's not an upstream bug.

On the other hand adding an event handler for the enter key being pressed while the radio buttons have the focus fixes the issue for Firefox and IE without doing harm to other browsers, since Opera just doesn't do anything by default when you press the enter key while the focus is on radio buttons. So a user of Opera who knows what his browser behaves like won't notice the change (because he doesn't press the enter key) and thus can't hate the change.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links