Last modified: 2013-08-09 18:10:48 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T19616, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 17616 - Enhanced recent changes JavaScript: clicking arrow should keep it in focus, keyboard accessibility
Enhanced recent changes JavaScript: clicking arrow should keep it in focus, k...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Recent changes (Other open bugs)
1.20.x
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Bartosz Dziewoński
: accessibility
Depends on:
Blocks: 35785
  Show dependency treegraph
 
Reported: 2009-02-22 19:07 UTC by Dan Wolff
Modified: 2013-08-09 18:10 UTC (History)
5 users (show)

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


Attachments
a simple patch (as long as the HTML looks like it currently does, no problems) (1.21 KB, patch)
2009-03-07 20:19 UTC, Dan Wolff
Details
simple patch (no problem as long as HTML is the same) (645 bytes, patch)
2009-03-14 12:06 UTC, Dan Wolff
Details

Description Dan Wolff 2009-02-22 19:07:10 UTC
In RC when multiple edits to the same page are made there is a blue arrow which one may click to show each specific edit. (well, if enhanced changes are enabled in the users preferences)

When the arrow is clicked it loses focus (since another arrow is displayed). When navigating using the keyboard this is very inconvenient - so the JS should actively change focus to the new arrow.
Comment 1 Dan Wolff 2009-03-07 20:19:40 UTC
Created attachment 5900 [details]
a simple patch (as long as the HTML looks like it currently does, no problems)
Comment 2 Dan Wolff 2009-03-14 12:06:03 UTC
Created attachment 5928 [details]
simple patch (no problem as long as HTML is the same)

Trying to create a real patch.
Comment 3 Krinkle 2011-03-03 13:23:04 UTC
The enhanced changes have changed a fair bit since 1.17, notably the use of CSS and jQuery utility functions instead of images directly in the DOM.

I think this is no longer an issue, someone else should confirm as well though (ideally the bug reporter) since I'm not entirely sure what the bug reporter meant and don't have a 1.15 around to experience the bug there.
Comment 4 Dan Wolff 2011-03-05 19:29:41 UTC
(In reply to comment #3)
> The enhanced changes have changed a fair bit since 1.17, notably the use of CSS
> and jQuery utility functions instead of images directly in the DOM.
> 
> I think this is no longer an issue, someone else should confirm as well though
> (ideally the bug reporter) since I'm not entirely sure what the bug reporter
> meant and don't have a 1.15 around to experience the bug there.

It seems like you are confused about the version numbers. The problem however still *does* exist at Wikimedia sites, e.g.:

* http://en.wikipedia.org/wiki/Special:RecentChanges (using 1.17wmf1 (r82948))
* http://test.wikipedia.org/wiki/Special:RecentChanges (using 1.17wmf1 (r83154))

Perhaps the version number should be updated?
Also, as of the deployed version, <img> tags are put directly into the HTML source; I don't recognize the "use of CSS and jQuery utility functions instead of images directly in the DOM".

Has this changed in 1.18?
Comment 5 DieBuche 2011-03-05 23:10:42 UTC
Steps to reproduce:
TAB through links in the page till you get to an arrow
Hit Enter
Focus is gone
Comment 6 Krinkle 2011-03-05 23:12:05 UTC
It has changed in trunk / 1.18, but the bug is stil there.

Instead of replacing the image itself, in 1.18 it has both and depending on whether the collapsible element is collapsed or expanded, one is display:none and the other display:block.
Comment 7 p858snake 2011-04-30 00:09:34 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 8 Sumana Harihareswara 2011-11-09 03:18:45 UTC
+reviewed since it seems that we have reviewed the code submitted, although if I'm wrong someone should remove that and add the need-review keyword. Thank you for the patch, Dan; do you have the time and interest to update your fix?
Comment 9 Dan Wolff 2011-11-09 14:37:23 UTC
I sure am interested in updating the fix, but I am preoccupied at the moment.
If I haven't provided an update within a month, my priorities have changed and you shouldn't count on me doing it.

Note:
Such a fix should also remove the newly introduced (and related) bug:
1. Tab to an arrow
2. Press enter
3. Notice that the URL has changed (a # is added)
Comment 10 Dan Wolff 2012-02-13 23:27:42 UTC
Relevant code: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/resources/jquery/jquery.makeCollapsible.js?revision=94389&view=markup#l180

Krinkle, is it necessary to prevent an <a> element from initiating the toggle?

We want to be able to click the <a> to toggle (or press enter while it is focused), so that can't be prevented.

I can think of a few solutions:
* Don't prevent <a> elements (is this prevention needed anywhere?)
* Add a parameter allowLinkAsTarget
* Add a class to $that element to indicate that links (i.e. .mw-collapsible-toggle.mw-collapsible-allow-link)
* Add a new function which doesn't prevent <a> elements


Also, as a note: We'll need to change the HTML to only have *one* <a> for both images, since we don't want to focus the <a> when the page loads (the toggling function is performed once).
Comment 11 Dan Wolff 2012-03-11 19:31:47 UTC
Krinkle and I have spoken briefly about this bug and it seems like the reason for preventing an <a> from initiating the toggle is to allow other links within toggle elements (use case: a complete table row is used for toggling, except that we want to have links in there too).

A fix that would solve this bug as well as allowing those links would be replacing line 180 above with:

if ( $(e.target).is('a') && !$that.is(e.target) ) {
Comment 12 Bartosz Dziewoński 2013-07-06 14:41:02 UTC
So it's 2013 now.

The script that does this has been rewritten again approximately two times since the last comment, and in my testing using MW 1.22 alpha (deployed on Wikipedias) using Opera 12.15 the focus is kept when using keyboard navigation (Shift+arrows, Enter).

Could someone verify? If this is the case, then it looks like this can be closed.
Comment 13 Dan Wolff 2013-07-07 16:20:59 UTC
I can confirm that focus is kept in Opera 12.15 (Linux) using shift+arrows, enter.


However, it does *not* work in Firefox 24 (Linux), not even when the setting to use cursor keys to navigate pages is active. In fact I can't focus it all in Firefox. I can't get it to work in Chromium 28 (Linux) either.

Looking at the source, there's no link, nor tabindex. My guess is that Opera makes items which have a click handler focusable as well.
Comment 14 Bartosz Dziewoński 2013-07-07 18:11:53 UTC
Hmm, yeah, Opera tends to be smarter than other browsers in places you don't expect. Let's try adding a tabindex and see what happens.

[Updating keywords.]
Comment 15 Gerrit Notification Bot 2013-07-07 18:27:13 UTC
Change 72371 had a related patch set uploaded by Matmarex:
jquery.makeCollapsible: Togglers accessibility

https://gerrit.wikimedia.org/r/72371
Comment 16 Gerrit Notification Bot 2013-07-09 00:44:15 UTC
Change 72371 merged by jenkins-bot:
jquery.makeCollapsible: Togglers accessibility

https://gerrit.wikimedia.org/r/72371
Comment 17 Bartosz Dziewoński 2013-07-09 00:51:31 UTC
Okay, that's merged. Can you check it out locally and see if it fixes the issue?

(Or feel free to register an account and test on my test wiki at http://users.v-lo.krakow.pl/~matmarex/testwiki/ , where I have just deployed it. Please ignore the spambots. All edits must have a non-empty summary or they will be rejected by the spam filter.)
Comment 18 Dan Wolff 2013-07-09 09:38:48 UTC
@Bartosz #17:
I tried creating an account on http://users.v-lo.krakow.pl/~matmarex/testwiki/. The arrow *is* focusable, and doesn't lose focus when clicking, but when it is focused, clicking Enter does nothing. So I'd say that so far this is *not* solved. I expect it to toggle when clicking Enter.
Comment 19 Gerrit Notification Bot 2013-07-09 12:32:36 UTC
Change 72719 had a related patch set uploaded by Matmarex:
jquery.makeCollapsible: Togglers keyboard accessibility

https://gerrit.wikimedia.org/r/72719
Comment 20 Bartosz Dziewoński 2013-07-09 12:34:07 UTC
Hmph. I though browsers handle this magically, but it turns out only Opera is smart enough. I deployed the pending patch above (comment 19) as well – can you test again now? :)

(Sorry about the back-and-forth.)
Comment 21 Dan Wolff 2013-07-10 08:38:30 UTC
(In reply to comment #20)
I tested it again in Firefox 24 (Linux) and Chromium 28 (Linux) and it does work (using the deployed version at http://users.v-lo.krakow.pl/~matmarex/testwiki/).

I'd say that that commit resolves this bug. Thanks!
Comment 22 Gerrit Notification Bot 2013-07-10 09:00:16 UTC
Change 72719 merged by TheDJ:
jquery.makeCollapsible: Togglers keyboard accessibility

https://gerrit.wikimedia.org/r/72719
Comment 23 Gerrit Notification Bot 2013-08-07 15:33:15 UTC
Change 78071 had a related patch set uploaded by TheDJ:
Accessibility: Don't arbitrarily override role

https://gerrit.wikimedia.org/r/78071
Comment 24 Gerrit Notification Bot 2013-08-09 18:10:19 UTC
Change 78071 merged by jenkins-bot:
Accessibility: Don't arbitrarily override role

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

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


Navigation
Links