Last modified: 2014-07-02 13:23:33 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 46336 - Tabbing from summary/textarea field should not go to the search box (vector)
Tabbing from summary/textarea field should not go to the search box (vector)
Status: NEW
Product: MediaWiki skins
Classification: Unclassified
Vector (Other open bugs)
All All
: Normal enhancement
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: 367 29199
  Show dependency treegraph
Reported: 2013-03-19 20:37 UTC by Helder
Modified: 2014-07-02 13:23 UTC (History)
9 users (show)

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


Description Helder 2013-03-19 20:37:44 UTC
The tab order was improved on r52465 for the subject field (see bug 19342), but it is still not good for the summary field:

Pressing TAB should go to the wpMinoredit checkbox (not to the search box).
Comment 1 Alex Monk 2013-03-19 21:51:46 UTC
wpMinorEdit is hidden...
Comment 2 Helder 2013-03-20 10:28:19 UTC
(In reply to comment #1)
> wpMinorEdit is hidden...

Not for me (likely due to some personal CSS) but anyway: it still shouldn't go to the search box, since this is not what happens in normal pages. The normal in a page such as
is to go from the summary to
1. wpMinoredit
2. wpWatchthis
3. wpSave
4. wpPreview
5. wpDiff
Comment 3 Jesús Martínez Novo (Ciencia Al Poder) 2013-09-13 18:09:52 UTC
This happens only in the Vector skin, and with Extension:Vector installed. It doesn't happen without it.

This is what happens:

ext.vector.collapsibleNav.js is setting the tabindex with JavaScript:

    // Get the highest tab index
    tabIndex = $( document ).lastTabIndex() + 1;
    // Fix the search not having a tabindex
    $( '#searchInput' ).attr( 'tabindex', tabIndex++ );

But LQT outputs the tabindex hardcoded in the HTML. Well, that's not a problem on static pages like a plain edit form, since ext.vector.collapsibleNav already finds the highest tabindex value and uses the next one for the search bar. But on LQT, since it loads the edit form with AJAX, the search input tabindex has been set already (with value "1"), which conflicts with the other tabindex of the LQT form. LQT edit area and summary field has tabindex 1, Other fields (minor edit, watch, save, preview) have tabindex starting from 3. Since the search field is later in the HTML, it takes precedence over tabindex higher than 1.

The solution is to use the same tabindex for all elements so all have the same priority and go in the order they're placed in the HTML
Comment 4 Jesús Martínez Novo (Ciencia Al Poder) 2013-09-13 18:26:54 UTC
I was thinking on fixing it myself, but I've found that it's using the standard editor of MediaWiki, so it may be something to fix not in LQT but in core. Is that "feasible"?

If we want to fix it only for LQT, then we'd have to use JavaScript to manually set the tabindex once the form has been populated with AJAX.
Comment 5 Nemo 2014-05-22 11:21:43 UTC
This is technically "fixed" right now by bug 39035, but we should not reintroduce it with bug 29199.
Comment 7 Jesús Martínez Novo (Ciencia Al Poder) 2014-05-22 19:27:21 UTC
Actually, I've tried on that page and it still doesn't work. If you edit a post, pressing tab moves the cursor to the summary, but the next tab moves the cursor to the search box.

On a new message, since there's no textarea, it goes straight to the search box.
Comment 8 Nemo 2014-05-22 19:30:08 UTC
(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #7)
> Actually, I've tried on that page and it still doesn't work.

That's what "[bug] verified current" meant, sorry for unclear terminology.
Comment 9 Gerrit Notification Bot 2014-05-23 16:35:07 UTC
Change 135057 had a related patch set uploaded by Nemo bis:
Add search box to existing "navigation" role
Comment 10 Gerrit Notification Bot 2014-05-24 20:49:15 UTC
Change 135057 abandoned by Bartosz Dziewoński:
Add search box to existing "navigation" role

This is not going to work / help, sorry :( (And there are so many patches for this issue, let's thin the herds a bit.)
Comment 11 Jesús Martínez Novo (Ciencia Al Poder) 2014-05-28 19:14:49 UTC
At this time, it's now resolved because the hardcoded tabindex in the search box has been removed (Gerrit change #135208) and has been deployed.

Sadly, the search box tabindex is going to be added again using JavaScript (in Gerrit change #135269), which will break it again on the next WMF deployment, at least for LQT.

Note that this bug report was originally for LQT, and then generalized after the Gerrit change #134801 fiasco.

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