Page MenuHomePhabricator

Searching while previewing an edit hangs Chrome tabs
Open, Needs TriagePublicPRODUCTION ERROR

Description

Steps to replicate the issue (include links if applicable):

  • Edit an article
  • Preview it
  • Attempt to use browser search

What happens?:

The tab completely locks up.

What should have happened instead?:

The tab doesn't lock up.

Event Timeline

Restricted Application changed the subtype of this task from "Bug Report" to "Production Error". · View Herald TranscriptSep 5 2025, 7:13 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
DLynch renamed this task from Searching while previewing an edit crashes browsers to Searching while previewing an edit hangs Chrome tabs.Sep 5 2025, 7:17 PM

Change #1185186 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/core@master] Revert "Edit: Split footer lists into columns"

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

I had to revert two commits at once there, but only one of them made it out into the release branch last week, so a completely separate revert patch will be needed specifically for a backport if we do one.

TNstringray in the linked thread reports it happening without needing any user interaction at all, about 3-4 second after they preview changes, but I cannot reproduce this. I think it's probably something non-default-gadget related.

Change #1185186 merged by jenkins-bot:

[mediawiki/core@master] Revert "Edit: Split footer lists into columns"

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

Change #1185192 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/core@wmf/1.45.0-wmf.17] Revert "Edit: Split footer lists into columns"

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

@Ryasmeen @EstherAmoo flagging this as it might be good to do a Root Cause Analysis on this since it escaped all the way to production and now has to be redone. An initial glance makes me wonder if we could write an automated test for it?

Change #1185192 merged by jenkins-bot:

[mediawiki/core@wmf/1.45.0-wmf.17] Revert "Edit: Split footer lists into columns"

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

Mentioned in SAL (#wikimedia-operations) [2025-09-05T20:17:17Z] <kemayo@deploy1003> Started scap sync-world: Backport for [[gerrit:1185192|Revert "Edit: Split footer lists into columns" (T401066 T403856)]]

Honestly, the steps involved in triggering this are simple but are also sufficiently niche that I'm not shocked nobody thought to test them. I have a hard time viewing this as anything other than a Chromium bug that we accidentally stumbled into.

That said, a headless browser test for this is presumably doable (I'm assuming there's a way to make Selenium activate the browser search). If we already had one that tested that searching for text successfully un-hides the collapsed footer, which was existing behavior, it'd have caught this. (But since it requires being the preview state, we might not have thought to specifically test that.)

Mentioned in SAL (#wikimedia-operations) [2025-09-05T20:23:18Z] <kemayo@deploy1003> kemayo: Backport for [[gerrit:1185192|Revert "Edit: Split footer lists into columns" (T401066 T403856)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-09-05T20:32:48Z] <kemayo@deploy1003> Finished scap sync-world: Backport for [[gerrit:1185192|Revert "Edit: Split footer lists into columns" (T401066 T403856)]] (duration: 15m 31s)

should an upstream ticket be filed, or can this be closed as fixed ?