Last modified: 2014-07-02 13:23:33 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).
wpMinorEdit is hidden...
(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 https://pt.wikibooks.org/wiki/teste?action=edit is to go from the summary to 1. wpMinoredit 2. wpWatchthis 3. wpSave 4. wpPreview 5. wpDiff
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
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.
This is technically "fixed" right now by bug 39035, but we should not reintroduce it with bug 29199.
Verified current with https://gerrit.wikimedia.org/r/134801 deployed on http://test.wikimedia.beta.wmflabs.org/wiki/Talk:Main_Page
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.
(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.
Change 135057 had a related patch set uploaded by Nemo bis: Add search box to existing "navigation" role https://gerrit.wikimedia.org/r/135057
Change 135057 abandoned by Bartosz Dziewoński: Add search box to existing "navigation" role Reason: This is not going to work / help, sorry :( (And there are so many patches for this issue, let's thin the herds a bit.) https://gerrit.wikimedia.org/r/135057
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.
