Page MenuHomePhabricator

Stop loading jquery.ui on Special:MediaSearch page
Closed, ResolvedPublic

Description

In the spirit of T271994, is there any way we can stop loading jquery.ui on Special:MediaSearch? This dependency is introduced by 3rd-party gadgets ( ext.gadget.Slideshow and ext.gadget.QuickDelete ) so the process won't be as simple as just re-working something in our code. However, jQuery UI is huge (around 350KB uncompressed - it's an entire JS framework essentially) and it's not being used here. Neither of these gadgets is compatible with this page.

It should be possible to disable all 3rd-party gadgets on Special:MediaSearch by adding: OutputPage->disallowUserJs();. Commons uses a gadget to translate page content (instead of the standard ULS widget); presumably this would also be disabled. Would this be acceptable? The page UI is already internationalized.

Alternatively, we could investigate the two gadgets in question and see if there is a way to prevent them from loading their dependencies on Special:MediaSearch. This would involve getting the community maintainers (assuming the gadgets are maintained) to agree to the changes.

Some useful links:

Event Timeline

After doing some digging, it looks like simply disabling all user JS on a given page is a bit of an extreme solution – this is intended for use in places like login screens only.

It looks like the modules in question declare jquery.ui as a dependency in two places – once in their gadget definition as a "hard" dependency (just like in a resource module); then again in the source code with mw.loader.using as a "soft" dependency. The latter alone ought to be sufficient. But ideally we would not load it on Special:MediaSearch at all – the page is not designed to integrate with 3rd-party tools in this way, so we are loading useless code.

If any change in the source code beyond this is needed to keep from loading unneeded libraries on this page, it may require a non-trivial amount of work. The AjaxQuickDelete gadget is > 2000 LOC of on-wiki code (no gerrit patches, no git history, etc) and it is used everywhere on Commons...

I've opened a discussion of this at the Commons Gadgets definition talk page; will report back if the community decides to move forward with my request to remove jquery.ui as a hard dependency for the gadgets in question (it is still handled properly as a "soft" dependency in each of them so it shouldn't impact users in any way, unless I am missing something).

Moving this task to "blocked" until then.

Thanks to @Krinkle for addressing this. I'm moving this to "verify on production" but we should be able to close this shortly!

It should be possible to disable all 3rd-party gadgets on Special:MediaSearch by adding: OutputPage->disallowUserJs();. Commons uses a gadget to translate page content (instead of the standard ULS widget); presumably this would also be disabled. Would this be acceptable? The page UI is already internationalized.

For future reference, I would say, no. disallowUserJs() is not a performance mechanism. It must be used as minimally as possible and is only appropiate on the handful of elevated security-sensitive pages we have. Otherwise, this would disrupt the user experience due to missing stylesheets and other site-wide mechanisms (some of which are user-controlled, some of which are site-wide). Two quick examples:

  • Wikis can make skin-level changes site-wide, such as a font changes (hyw.wikipedia.org and pnb.wikipedia.org), or sidebar changes (zh.wikipedia.org, and eu.wikipedia.org), theme colors (green vi.wikipedia.org), or logo overlays via Common.css for temporary campaigns and celebrations.
  • Users may have gadgets or scripts that add controls or change minor things in the layout that are not specific to the page. E.g. an experimental or alternate way of making a skin responsive, or adding controls in the headers or sidebar that can be activated from anywhere that lead to a non-modal experience, or adding an icon or backbground color to the user tools area to differentiate "personal" from "work" accounts.

I have a modest few myself actually, shown below, that apply globally:

capture.png (1×2 px, 191 KB)

In generall all these costs are either small, or chosen by the user. The case of large gadget-based applications enabled site-wide but only relevant on a subset of pages, is something that fortunately doesn't happen often.

But when it does happen, and said gadget is enabled by default, then it's something we can either work with the community on to improve (as we did in this case), or by possibly intervening to make the gadget opt-in until the issue is resolved, or in the future through a simple condition in the gadget definition as per T63007. (This is currently awaiting stewardship assignment to determine which team owns it.)