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.

Per comments of Ciencia, marking this as specific to LQT again, since that is the only situation where we still seem to encounter it.

@Nemo_bis If this is the reason you think that this is High priority, please file a Gerrit patch right now, otherwise I will also downgrade priority of this task.

I will note that it really does not matter what the "Priority" field is set to, because no one is working on any LiquidThreads tasks anyway.