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?

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)

adding @dcausse for Cirrus insights

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

In T205991#4643303, @matmarex wrote:

(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