Revert "Restore search box tabindex"
authorMattflaschen <mflaschen@wikimedia.org>
Sat, 24 May 2014 14:54:42 +0000 (14:54 +0000)
committerMatthew Flaschen <mflaschen@wikimedia.org>
Sat, 24 May 2014 15:00:51 +0000 (11:00 -0400)
This does not restore the same behavior as collapsibleNav.js had.  That
used $( document ).lastTabIndex() + 1 in JavaScript.  This means it
would dynamically put the search box's tabindex after other elements.

This commit specified an explicit value of 1.  This is normally used
for forms.  For example, 1 is the username field on Special:UserLogin.
Thus, this made tabbing from the username field take you to the search
input.  It also caused issues with at least MassMessage.

Another solution is necessary, whether it's dynamically adding it with
JavaScript as before, using a different PHP-generated tabindex, both
(PHP-generated tabindex overridden by JavaScript), or something else.

In the meantime, this reverts to avoid the mentioned regressions.

This reverts commit be76751e8c7a8c33b8a9f41faba78592a22ded09.

Bug: 29199
Bug: 65704
Change-Id: Iaea60834aa8f1564aca50c21ee62ae01f958cc65

includes/SkinTemplate.php

index cf8b3fc..08816ad 100644 (file)
@@ -1987,7 +1987,6 @@ abstract class BaseTemplate extends QuickTemplate {
                        'name' => 'search',
                        'placeholder' => wfMessage( 'searchsuggest-search' )->text(),
                        'value' => $this->get( 'search', '' ),
-                       'tabindex' => 1
                );
                $realAttrs = array_merge( $realAttrs, Linker::tooltipAndAccesskeyAttribs( 'search' ), $attrs );
                return Html::element( 'input', $realAttrs );