(Sorry for necroposting I guess. Just trying to update with what I see... maybe already solved / not relevant anymore)

Change #1011334 abandoned by Jforrester:

[mediawiki/core@master] Specials: Proved UnlistedFormSpecialPage and ListedRedirectSpecialPage

Reason:

Lack of interest.

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

Change #1057978 merged by jenkins-bot:

[mediawiki/extensions/CirrusSearch@master] i18n: Drop 'cirrussearch-ignored-headings', now unused

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

Discussed this with @Ladsgroup
We concluded that this is simply not really worth the effort in the this patch round. As Wikimedia doesn't rely on it, rearchitecting the testcases of Wikimedia to not so strongly depend on searchindex will needlessly complicate things. Instead, I'll provide maintenance script to convert to innodb for those who desire this.

Change #1059485 merged by jenkins-bot:

[mediawiki/core@REL1_42] PrefixSearch: Make sure $prefix is a string

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

Change #1059485 had a related patch set uploaded (by RhinosF1; author: Lucas Werkmeister (WMDE)):

[mediawiki/core@REL1_42] PrefixSearch: Make sure $prefix is a string

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

Change #951900 merged by jenkins-bot:

[mediawiki/core@master] WikiTextStructure: Drop message fallback to old cirrussearch message

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

Change #1057978 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/CirrusSearch@master] i18n: Drop 'cirrussearch-ignored-headings', now unused

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

@MarkTraceur is this possibly for media search for your team?

Indeed, Rdbms is detecting this and reporting it. It's not causing it. It's not clear which component is causing it, but they seem to have Search as common referer, perhaps we can investigate from there to see what it is?

This has been rolling around in my head for a while and something related came up today, so I wanted to jot down some notes to my future self, or to anyone else who may work on this.

@Paladox It would be fantastic if you could continue your work.

@Jdlrobson "Search" is white in PROD and fail contrast while Test.Wiki was black (as seen in my previous test)

This is currently blocked on all our testcases relying on tables to be cloneable, but innoDB cannot create a TEMPORARY table of a table that has a FULLTEXT index.

Hey @Prototyperspective, these sound like reasonable ideas for how to improve the user experience here, so I want to bring this to the attention of the Structured Data team (who are the official maintainers of this feature AFAIK). @AUgolnikova-WMF or @Sannita may be able to move this task to the appropriate place for triaging. I will say that I think the team's current focus is on improving UploadWizard, so this might not be an immediate priority.

Thanks for CCing. @egardner Yes of course. The Media search is much better. However, there are several problems with it due to which in practice one often has to resort to the Special search. The better solution would be to improve Media search further so that Special search is not needed anymore at all (that would be separate issues). Two main problems with it are that Cat-a-lot (which is very useful especially on WMC) does not work in Media search and that it doesn't have this dropdown for search operators.

Hi @Prototyperspective – are you familiar with Special:MediaSearch on commons? Here's an example of it in action:

CC'ing more folks who were involved in this change to get another opinion in this ticket.

I already knew about this research and agree with the findings and what it means for Wikipedia. I don't think it applies here much or at all because these are search results. The user usually just glances over them, like their filetitles and thumbnails. The special search looks quite broken currently and there could at least be settings to make use full width (actually on Wikipedia there now seems to be a reading view setting for width so I guess the same could be used here).

the space should be used until a preview is shown there, just like with the modern not-broken wall-of-images-view Media search results (example) which use all available width until an item is clicked for preview

@Aklapper That only relates to what would be needed for this problem to be fixed – in specific that the default for WMC needs to be different than other Wikimedia sites, eg site-specific changes on top of the default page layout that makes it use a wider width.

The empty space is used for interwiki search results or previews in other cases. Page layout shouldn't differ across pages, thus empty space in this case when there are no interwiki search results or previews.

@Aklapper I don't think this should be closed and it seems way to quick to close it – I don't understand your explanation. When I click on a file in these search results the page is opened instead of a preview showing on the right. Whether or not it's intentional doesn't make it any better, if anything it would be a bigger problem and indicate that it would be easier to fix. And remains the case that the Special search UI is broken. Could you please clarify what you mean in the sense of why you think this is not a valid issue?

@Aklapper That is not true. It does work well here for example (which has been very useful to find files missing in the cat) and this category contains thousands of files.

The operator works but AFAIK negation is currently not supported.