Screencast – I’m just repeatedly scrolling down:

This seems to be a regression in OOUI 0.50.1 or 0.50.2 – I can reproduce it locally on Merge "Update OOUI to v0.50.2" (which bumps OOUI from 0.50.0 to 0.50.2) but not on its parent.

Can also be reproduced with the log type or tag filters on https://en.wikipedia.beta.wmflabs.org/wiki/Special:Log?limit=1 (the ?limit=1 is important), so it’s not specific to Wikidata.

What happens is that the dropdown menu / select widget no longer clamps its height to the screen height (becoming scrollable internally), but instead makes the whole page scrollable. This interacts badly with another feature where the dropdown will make itself invisible if the initial input scrolls outside of the visible area (you can try that on Special:Log without ?limit – open one of the dropdowns and then scroll down). If this happens, but the page as a whole was only scrollable due to the dropdown because there’s not enough content on it otherwise, then as soon as the dropdown becomes invisible the page snaps right back up. But this brings the initial input back into view again, so the dropdown immediately becomes visible again. And this just repeats over and over as you scroll down.

Yeah, I was thinking it might be.

A git bisect in OOUI points at build: Update eslint-config-wikimedia to 0.28.2 and autofix as the culprit, so I suspect one of the $.extend() ⇒ Object.assign() changes needs an extra {} argument in front (we’ve had other issues like this recently).

Hm, at a glance I didn’t see any Object.assign() calls where the first argument isn’t a fresh object (either an object literal or a variable that’s assigned an object literal or Object.assign() result earlier in the method body) in that diff. Maybe it’s one of the arrow function changes then, with a changed meaning of this?

(Edit: for the record, it turns out that all the arrow function changes happened outside of src/, so it wasn’t this either. I eventually found the buggy code by switching individual directories and then files between the old and new version.)

Well, somehow, just the following diff is enough to make it work again:

diff --git a/resources/lib/ooui/oojs-ui-core.js b/resources/lib/ooui/oojs-ui-core.js
index 3bae5aaa0b..d26e523f4e 100644
--- a/resources/lib/ooui/oojs-ui-core.js
+++ b/resources/lib/ooui/oojs-ui-core.js
@@ -5711,7 +5711,7 @@ OO.ui.mixin.ClippableElement.prototype.clip = function () {
 		$viewport = this.$clippableScrollableContainer;
 		viewportRect = $viewport[ 0 ].getBoundingClientRect();
 		// Convert into a plain object
-		viewportRect = Object.assign( {}, viewportRect );
+		viewportRect = $.extend( {}, viewportRect );
 	}
 
 	// Account for scrollbar gutter
@@ -5741,7 +5741,7 @@ OO.ui.mixin.ClippableElement.prototype.clip = function () {
 
 	let itemRect = $item[ 0 ].getBoundingClientRect();
 	// Convert into a plain object
-	itemRect = Object.assign( {}, itemRect );
+	itemRect = $.extend( {}, itemRect );
 
 	// Item might already be clipped, so we can't just use its dimensions (in case we might need to
 	// make it larger than before). Extend the rectangle to the maximum size we are allowed to take.

(That’s a diff in core; in OOUI, that code lives in src/mixins/ClippableElement.js.)

I’m guessing this is because of some subtle differences in how $.extend() vs. Object.assign() treat inherited and/or otherwise-special properties? getBoundingClientRect() probably returns an object that’s a bit more special than Object.assign() can deal with?

Yeah, the getBoundingClientRect() result has no own properties:

» Object.getOwnPropertyNames(temp0.getBoundingClientRect())
← Array []

And Object.assign only copies the enumerable own properties.

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

[oojs/ui@master] Fix getBoundingClientRect() copying

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

In principle, we might be able to unblock the train by reverting the OOUI update; but I don’t know whether that’s okay to do or not (I asked here FWIW), and the people who can answer that are probably roughly the same people who can make a new OOUI release anyway, so I expect we may as well wait for the above change to be merged and released and then update to OOUI v0.50.3.

In T369010#9943717, @Lucas_Werkmeister_WMDE wrote:

I expect we may as well wait for the above change to be merged and released and then update to OOUI v0.50.3.

Yes, agreed.

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

[oojs/ui@master] WIP: Add test for ClippableElement

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

Change #1051314 merged by jenkins-bot:

[oojs/ui@master] Fix getBoundingClientRect() copying

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

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

[mediawiki/core@master] Update OOUI to v0.50.3

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

Change #1051403 merged by jenkins-bot:

[mediawiki/core@master] Update OOUI to v0.50.3

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

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

[mediawiki/core@wmf/1.43.0-wmf.12] Update OOUI to v0.50.3

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

Change #1051417 merged by jenkins-bot:

[mediawiki/core@wmf/1.43.0-wmf.12] Update OOUI to v0.50.3

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

Mentioned in SAL (#wikimedia-operations) [2024-07-02T17:10:21Z] <jforrester@deploy1002> Started scap sync-world: Backport for [[gerrit:1051416|Update OOUI to v0.50.3]], [[gerrit:1051417|Update OOUI to v0.50.3 (T369010)]]

Mentioned in SAL (#wikimedia-operations) [2024-07-02T17:14:37Z] <jforrester@deploy1002> jforrester: Backport for [[gerrit:1051416|Update OOUI to v0.50.3]], [[gerrit:1051417|Update OOUI to v0.50.3 (T369010)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-07-02T17:20:27Z] <jforrester@deploy1002> Finished scap: Backport for [[gerrit:1051416|Update OOUI to v0.50.3]], [[gerrit:1051417|Update OOUI to v0.50.3 (T369010)]] (duration: 10m 06s)