Page MenuHomePhabricator

Tabbing from LQT editor's summary/textarea fields should not go to the search box in Vector skin
Closed, ResolvedPublic

Description

The tab order was improved on r52465 for the subject field (see T21342: LiquidThreads tab order is confusing), but it is still not good for the summary field:

  1. Open https://translatewiki.net/w/i.php?title=Support&useskin=vector
  2. Reach the first message you can find
  3. Click the dropdown menu next to it and then "edit"

I. Observed: The cursor is in the main textarea

  1. Tab twice

Pressing TAB should go to the wpMinoredit checkbox (not to the search box), after the edit summary.

See Also:

Details

Reference
bz46336

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:31 AM
bzimport added a project: Vector.
bzimport set Reference to bz46336.
bzimport added a subscriber: Unknown Object (MLST).

(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.

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.

TheDJ added a subscriber: TheDJ.

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

He7d3r set Security to None.
Jdforrester-WMF renamed this task from Tabbing from summary/textarea field should not go to the search box (vector) to Tabbing from LQT editor's summary/textarea fields should not go to the search box in Vector.Aug 4 2016, 11:29 PM
Jdforrester-WMF updated the task description. (Show Details)
Jdforrester-WMF lowered the priority of this task from Medium to Lowest.Aug 4 2016, 11:34 PM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

LiquidThreads has been replaced by StructuredDiscussions on all Wikimedia production wikis (except one, which will be done soon). It is no longer under active development or maintenance, so I'm re-classifying all open LQT tasks as "Lowest" priority.

Nemo_bis raised the priority of this task from Lowest to Medium.Aug 5 2016, 7:31 AM
Jdforrester-WMF lowered the priority of this task from Medium to Lowest.Aug 9 2016, 7:20 PM
Jdforrester-WMF removed a project: VisualEditor.
Jdlrobson renamed this task from Tabbing from LQT editor's summary/textarea fields should not go to the search box in Vector to Tabbing from LQT editor's summary/textarea fields should not go to the search box in Vector skin.Jun 29 2017, 9:16 PM
Jdlrobson moved this task from 2014-15 Q4 to Tracking on the Readers-Web-Backlog board.
Nemo_bis raised the priority of this task from Lowest to High.Feb 24 2019, 8:40 AM

Restore information removed with now-invalid rationale; also increase priority due to growing focus on accessibility in the Wikimedia movement.

@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.

Volker_E claimed this task.
Volker_E added a subscriber: Volker_E.

This should have been resolved in a turn of pages, by removing tabindex from Vector search input in T226148.