Page MenuHomePhabricator

"Select options below to be global" missing a checkbox
Closed, ResolvedPublic

Description

With the new new OOUI version of Preferences, the "Select options below to be global" text is missing the checkbox to enable/disable all options below. It becomes unclear what that text is referring to.

Console error:

Problem(s):

The infusion fails on mw-input-wpcirrussearch-pref-completion-profile-global -- it cannot find an associated widget, because the Search tab in preferences has a group of widgets (radio buttons), not just one, so the infusion fails and does not continue, causing it to not load the select-all checkbox at all.

Quick fix:

The infusion should be in a try/catch block so that if it fails, it doesn't fail the entire page. We can't always trust or know other external extensions and how they set their preference definitions. This will prevent the crash on the entire page (all tabs), but will not fix the problem with CirrusSearch preferences and they won't be available to change in GlobalPreferences until the longer-term solution is fixed.

Longer-term fix:

CirrusSearch should be examined to see why the grouping is different than other page groupings, which makes GlobalPreferences add a single checkbox to the entire block rather than individual checkboxes to each option.

Event Timeline

DannyH created this task.Oct 2 2018, 5:03 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 2 2018, 5:03 PM
Niharika renamed this task from "Select options below to be global" misaligned in new Preferences to "Select options below to be global" missing a checkbox.Oct 2 2018, 5:53 PM
Niharika triaged this task as Unbreak Now! priority.
Niharika updated the task description. (Show Details)
Restricted Application added subscribers: Liuxinyu970226, TerraCodes. · View Herald TranscriptOct 2 2018, 5:53 PM
aezell assigned this task to Mooeypoo.Oct 2 2018, 6:37 PM
aezell moved this task from Ready to In Development on the Community-Tech-Sprint board.
aezell added a subscriber: aezell.

@Mooeypoo and I discussed this and we think it's a race condition. This happens when the objects are not available in the DOM when we try to added the select all checkbox to them.

She is investigating a fix.

The infusion fails on '.mw-input-wpcirrussearch-pref-completion-profile-global' -- it cannot find an associated widget, because the search completion has a group of widgets, not just one, so the infusion fails.

Quick fix:

  • The infusion should be in a try/catch block so that if it fails, it doesn't fail the entire page. We can't always trust or know other external extensions and how they set their preference definitions.

This will prevent crash, but will not fix the problem with CirrusSearch preferences and they won't be available to change in GlobalPreferences until the longer-term solution is fixed.

Longer-term fix:

  • Cirrus search should be examined to see why the grouping is different than other page groupings, which makes GlobalPreferences add a single checkbox to the entire block rather than individual checkboxes to each option.

This will prevent crash, but will not fix the problem with CirrusSearch preferences and they won't be available to change in GlobalPreferences until the longer-term solution is fixed.

What do you mean by prevent crash? And what's the problem with CirrusSearch preferences?

Restricted Application added a project: Discovery-Search. · View Herald TranscriptOct 2 2018, 7:46 PM
Niharika updated the task description. (Show Details)Oct 2 2018, 8:14 PM

CirrusSearch should be examined to see why the grouping is different than other page groupings, which makes GlobalPreferences add a single checkbox to the entire block rather than individual checkboxes to each option.

This needs more clarification. A single checkbox is what is expected because it's a group of radio buttons. This is no different from what the Skin setting looks like under Appearance. Why is it behaving differently?

Sorry, my computer almost died so the above was a bit of a quick hit-and-run comment. Let me be more clear:

GlobalPreferences checkbox connects to an "associated widget" that is the preference input on the page. When you click the checkbox, it enables the associated widget. For most preferences, the widget is straight forward -- an input, a select box, a checkbox, etc. There are a couple of slightly advanced cases that are covered as well, like in the case of the skin selection, which is a group of radio widgets -- but OOUI recognizes those as a single grouped widget, and can enable/disable them as needed.

In the case of CirrusSearch preferences, the grouping of radio widgets is not the same as the skin one; it looks like the preference is sorted with a slightly weird construct of containers. This means that when the checkbox looks for its associated widget, it doesn't find a proper one, and when it tries to use OO.ui.Infuse to make it into an OOUI dynamic widget, it fails -- which then makes the whole code crash and burn.

There are two things we must do, then:

  • The Search preferences should be fixed to be more similar to the way we construct the other preferences, so that they are considered a single preference rather than a container of containers.
  • We have to have a try/catch when we infuse, regardless, because Preferences can include things from other extensions that we can't always trust know how to do things "the standard way" so at the very least, we should make sure that the code fails gracefully rather than in a dumpster fire like what happened here.

I was working on a quickfix for "try/catch" when my computer died; I'll submit something soon so at least we have things working and not failing in production -- but the try/catch protection wouldn't fix the CirrusSearch preferences, which means that the checkbox for "Global Preferences" associated with the search preferences will not work, and users will not be able to override search prefs in Global Preferences until those preferences themselves are fixed to use the standard input group -- or until the owners of that preference decide to build a php+js OOUI widget (similar to what we did with CheckMatrix) so that the "non standard" operation works separately.

Change 464063 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/extensions/GlobalPreferences@master] Fail gracefully if we failed to find associated widget

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

Change 464063 merged by MaxSem:
[mediawiki/extensions/GlobalPreferences@master] Fail gracefully if we failed to find associated widget

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

Change 464070 had a related patch set uploaded (by MaxSem; owner: Mooeypoo):
[mediawiki/extensions/GlobalPreferences@wmf/1.32.0-wmf.23] Fail gracefully if we failed to find associated widget

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

Change 464071 had a related patch set uploaded (by MaxSem; owner: Mooeypoo):
[mediawiki/extensions/GlobalPreferences@wmf/1.32.0-wmf.24] Fail gracefully if we failed to find associated widget

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

Change 464071 merged by jenkins-bot:
[mediawiki/extensions/GlobalPreferences@wmf/1.32.0-wmf.24] Fail gracefully if we failed to find associated widget

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

Mentioned in SAL (#wikimedia-operations) [2018-10-03T00:19:29Z] <ladsgroup@deploy1001> Synchronized php-1.32.0-wmf.24/extensions/GlobalPreferences/resources/ext.GlobalPreferences.global.ooui.js: SWAT: [[gerrit:464071|Fail gracefully if we failed to find associated widget (T205991)]] (duration: 00m 55s)

Change 464070 merged by jenkins-bot:
[mediawiki/extensions/GlobalPreferences@wmf/1.32.0-wmf.23] Fail gracefully if we failed to find associated widget

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

Mentioned in SAL (#wikimedia-operations) [2018-10-03T00:41:27Z] <ladsgroup@deploy1001> Synchronized php-1.32.0-wmf.23/extensions/GlobalPreferences/resources/ext.GlobalPreferences.global.ooui.js: SWAT: [[gerrit:464070|Fail gracefully if we failed to find associated widget (T205991)]] (duration: 00m 57s)

Niharika removed Mooeypoo as the assignee of this task.Oct 3 2018, 2:49 AM
Niharika lowered the priority of this task from Unbreak Now! to Normal.
Niharika added subscribers: Smalyshev, EBernhardson.

The fix has been merged and it mitigates the crash. The current state with the Search tab is that the global checkbox does not control activation/deactivation of that preference but it still "works". The preference is saved globally only when the checkbox is enabled.

@Smalyshev @EBernhardson Pinging you both as CirrusSearch maintainers. The custom OOUI widget(s) in the Search tab does not play nice with GlobalPrefs. See the work done as part of T172585 and T201340 to see how we worked around this for the notification checkmatrix which is also non-standard. We'd be happy to provide more guidance on this.

adding @dcausse for Cirrus insights

matmarex removed a subscriber: matmarex.Oct 4 2018, 6:37 PM

(Please @mention me if you need my input. Looks like the main issue is fixed and everything @Mooeypoo and @Niharika wrote above is correct, so I assume I have nothing else to do here.)

(Please @mention me if you need my input. Looks like the main issue is fixed and everything @Mooeypoo and @Niharika wrote above is correct, so I assume I have nothing else to do here.)

That's correct; my recommendation is to make the radio buttons standard (similar to skins) rather than make a special widget just for that case. That would mean reorganizing the text blobs, though, so that's a product decision on their end.
We can help guide the search team if they want to create a specialized OOUI widget, but I think that standardizing is more straight forward and less of a hassle.

Change 466809 had a related patch set uploaded (by EBernhardson; owner: EBernhardson):
[mediawiki/extensions/CirrusSearch@master] Standardize autocomplete preferences

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

Looks like there is a separate task requesting that the preference be standardized (and Erik's patch seems to resolve it): T203988: On Special:Preferences>Search page, the descriptive text for each options should have the same font as other descriptive texts on other tabs

Change 466809 merged by jenkins-bot:
[mediawiki/extensions/CirrusSearch@master] Standardize autocomplete preferences

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