Page MenuHomePhabricator

Remove jquery.checkboxShiftClick from default payload
Open, MediumPublic

Description

The feature

On all page loads (regardless of wiki, user, skin or url), there is JavaScript looking for checkboxes. It listens to when they are clicked, and on successive clicks it checks if the Shift-key is being held. If it is, it will enable all checkboxes between the current and last-clicked checkbox.

Background

This functionality has existed since 2008, introduced in MediaWiki 1.6 with r13173 (2afce2e3f58), as requested in T4115. The primary use case for it was the checkboxes on Special:Undelete. This still exist today:

capture.png (1×1 px, 166 KB)

Since then, the feature has been:

  • (2010) Ported to ResourceLoader as part of mw.util.init. (r75287 / c28ba5133).
  • (2010) Factored out into its own module, as dependency of mediawiki.util, called from mw.util.init. (r75546 / e2e6fb563b)
  • (2011) Decoupled from mw.util.init into a general mediawiki.page.ready module for initialisation code on page views. This made mediawik.util free of side-effects, per T28799. (r90605 / 95173d11f)
Today

It is currently registered as its own module, but only ever used as part of mediawiki.page.ready. Per the concerns outlined at T202154 and Page load, this does not make sense as its own module bundle.

It is currently loaded on all page views, but page views are by definition also the very context it can never be used on given wikitext cannot generally create forms with many checkboxes. It is only needed on Special:Undelete and perhaps a handful of other special pages (to be decided).

It currently applies to any checkbox anywhere on the page. This might trigger unexpectedly. It should instead be opt-in. For example, with a class name on a containing element (form, fieldset, etc).

Some questions:

  • Where does it currently apply?
  • Where do we want this to apply?

Some ideas:

  • Make it part of mediawiki.htmlform (similar to autoinfuse and other misc form utilities)
  • Remove as generic snippet, and inline it where needed , e.g. for Special:Undelete as part of mediawiki.special.undelete.
  • Provide it as OOUI feature and offer only on OOUI-powered pages.
  • Remove the feature entirely?

Event Timeline

Here's a perhaps surprising place to see it in action:

Special:Block

export.png (1×1 px, 141 KB)

Here's a perhaps surprising place to see it in action:

Special:Block

export.png (1×1 px, 141 KB)

Wow. Yeah, that's a serious anti-feature.

Change 536543 had a related patch set uploaded (by Krinkle; owner: Fomafix):
[mediawiki/core@master] Integrate module 'jquery.checkboxShiftClick' into 'mediawiki.page.ready'

https://gerrit.wikimedia.org/r/536543

Change 536543 merged by jenkins-bot:
[mediawiki/core@master] Integrate module 'jquery.checkboxShiftClick' into 'mediawiki.page.ready'

https://gerrit.wikimedia.org/r/536543

I don't think we should remove this feature. There are certainly parts of MediaWiki where it is not helpful (like the block interface), and parts where we implemented more clever interfaces (e.g. the search page used to have a huge block of checkboxes for namespaces), but there are others where it is useful, for example the revision deletion/undeletion interface.

image.png (1×1 px, 489 KB)

I don't think we should remove this feature.

"…from default payload", not from MW. Presumably we'd still load it on a few special pages like delete/undelete, which is what it was meant for.

The "Remove the feature entirely?" in task description suggest that removing it was considered as an option and I wanted to make sure you don't do that.

Krinkle changed the task status from Open to Stalled.Sep 23 2019, 8:32 PM
Krinkle moved this task from Inbox, needs triage to Blocked (old) on the Performance-Team board.

Blocked until we decide how to move on this w.r.t. product and features.

Niharika subscribed.

From my perspective as the PM on Anti-Harassment which is currently responsible for Special:Block, I do not mind if we remove it from that page. It was not an intentional feature.

Krinkle changed the task status from Stalled to Open.Sep 30 2019, 10:29 PM
Krinkle triaged this task as Medium priority.

Thanks!

I'd like to ask our users via Tech-News whether they are aware of any places (apart from Special:Undelete) where our checkbox-shift code is currently working in a way that they find useful. It is my expectation that this is most likely unexpected and/or actively causing bugs or other mistakes. For those cases, removing the code will improve the experience. If there are cases where this code is (accidentally) working correctly, then I need to know about it. It is no problem to keep loading it in a small number of cases.

Proposed text for Tech News:

There is JavaScript code on Special:Undelete for administrators, this makes it possible to hold "Shift" and automatically select multiple checkboxes This code is also loaded by accident on other special pages, and on articles. This makes pages slower. If you know of other special pages where this is currently useful please let the developers know at T232688.

I'd like to ask our users via Tech-News whether they are aware of any places (apart from Special:Undelete) where our checkbox-shift code is currently working in a way that they find useful.

It is very useful on Special:Contributions and action=history for revision deletion.

Krinkle updated the task description. (Show Details)

Anywhere where revision deletion or suppression could be used, it'd be useful, in particular I'm thinking of Special:Log. It's useful on Special:Nuke as well. I'm not sure it's needed on Special:UserRights, although it would make removal of redundant rights after getting sysop easier, albeit rare.

action=history is correct @JJMC89, but I believe the checkboxes on Special:Contribs are due to a userscript. Still, if T78092 ever happens, it'd be needed for sure. Likewise, on Special:DeletedContributions (T121297) and the AbuseLog (T144096).

I believe the checkboxes on Special:Contribs are due to a userscript.

Oh, you're right.

Jdlrobson subscribed.

Trying to find a better tag for this. The MediaWiki-User-Interface tag is too generic. Open to better ideas.

This task is not about an issue with the delivery system, nor with a core module maintained as part of ResourceLoader (see Phab project description). I tagged MW-UI since this is a core module provided by OutputPage or Skin.

However, part of my proposal is to not make it be that anymore, but rather localise it to HTMLForm, or even embed it directly in the Page-delete and User-block features respectively (no re-use needed).