Width bug in oojs-ui-toolbars
Closed, ResolvedPublicBUG REPORT
Actions

Assigned To

Authored By

	zoe
	Feb 3 2025, 5:28 PM

Project Tags

Referenced Files

	F58357792: Screenshot 2025-02-04 at 20.21.08.png
	Feb 4 2025, 8:24 PM

	F58357793: Screenshot 2025-02-04 at 20.21.12.png
	Feb 4 2025, 8:24 PM

	F58348244: Screenshot 2025-02-03 at 17.24.42.png
	Feb 3 2025, 5:28 PM

	F58348243: Screenshot 2025-02-03 at 17.24.36.png
	Feb 3 2025, 5:28 PM

Subscribers

Description

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

This requires a situation where a dropdown menu is rendered in specific positions and so I'm not sure it can be replicated on the main branch.

This patchdemo will allow you to reproduce the bug
Alternatively, apply this patch (at patchset #3 at time of writing) and use the mobile VE skin by appending ?useformat=mobile#/editor/0 to a wiki url
Switch on responsive layout mode and set it to mobile phone size. On my machine, 442 pixels or fewer worked.
Click on a dropdown menu that's too far to the right, in this case the + menu which contains "link"

What happens?:

The dropdown menu renders at full width

What should have happened instead?:

The dropdown menu should be narrower, as it is either with the style menu (which is further left) or with a browser window which is wide enough

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

Expected behaviour:

Screenshot 2025-02-03 at 17.24.36.png (986×890 px, 49 KB)

Actual behaviour:

Screenshot 2025-02-03 at 17.24.42.png (976×986 px, 35 KB)

In debugging I have found that in oojs-ui-core.js at line 5785 seems to make the difference:

	const clipWidth = allotedWidth < naturalWidth;

This appears to be true when the bug manifests and false when it does not.

I also tried switching the two dropdown menus around near modules/ve-mw/init/targets/ve.init.mw.MobileArticleTarget.js:75 and found that the issue continued to manifest on the second of the two items, ie, that the + menu behaved as intended and instead the 'Style' menu manifested the bug.

Details

Related Changes in Gerrit:

	Subject	Author	Repo	Branch	Lines +/-
	Update OOUI to v0.51.6	VolkerE	mediawiki/core	master	+113 -121
	Change how we place PopupToolGroups on narrow displays	Zoe	oojs/ui	master	+12 -5

Customize query in gerrit

Related Objects
Search...

Status	Subtype	Assigned	Task
Open		None	T272515 Provide nice ways for editors to insert and update Wikifunctions calls in VisualEditor
Resolved		Jdforrester-WMF	T383106 [25Q3] Provide Wikifunctions integration in articles on Dagbani Wikipedia
Resolved		Jdforrester-WMF	T376521 Enable one WF use case in a smaller language Wikipedia
Resolved		Jdforrester-WMF	T373118 Implement initial integration of WF call nodes with VisualEditor
Open		ppelberg	T383145 [Abstract Wikipedia] Adding Wikifunctions in VE (desktop + mobile)
Stalled	Feature	None	T431864 TemplateWizard should be extended to mobile web
Stalled		Esanders	T385851 Introduce additional tools within the mobile visual editor's "+" menu
Resolved		zoe	T382454 Create space for additional editing tools within the mobile visual editor toolbar
Resolved	BUG REPORT	zoe	T385507 Width bug in oojs-ui-toolbars

Event Timeline

zoe created this task.Feb 3 2025, 5:28 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 3 2025, 5:28 PM

zoe mentioned this in T382454: Create space for additional editing tools within the mobile visual editor toolbar.Feb 3 2025, 5:29 PM

There's a comment about what this part of the code is solving:

// The hacks below are no longer needed for Firefox and Chrome after T349034,
// but may still be needed for Safari. TODO: Test and maybe remove them.

// Set overflow to 'scroll' first to avoid browser bugs causing bogus scrollbars (T67059),
// then to 'auto' which is what we want.

(For links: T349034 and T67059)

It looks like their isn't room to expand either left or right, so it chooses neither. In this case we should probably pick one direction (left) and then move the menu to allow the desired width.

Based on the comments in OO.ui.PopupToolGroup.prototype.setActive this is intended behaviour as currently written:

Line 332

// Try anchoring the popup to the preferred side first
this.setHorizontalPosition( preferredSide );

if ( this.isClippedHorizontally() || this.isFloatableOutOfView() ) {
	// Anchoring to the preferred side caused the popup to clip, so anchor it
	// to the other side instead.
	this.setHorizontalPosition( otherSide );
}
if ( this.isClippedHorizontally() || this.isFloatableOutOfView() ) {
	// Anchoring to the right also caused the popup to clip, so just make it fill the
	// container.

zoe claimed this task.Feb 4 2025, 7:29 PM

Change #1117246 had a related patch set uploaded (by Zoe; author: Zoe):

[oojs/ui@master] Change how we place PopupToolGroups on narrow displays

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

gerritbot added a project: Patch-For-Review.Feb 4 2025, 8:08 PM

Test wiki created on Patch demo by Zoe-WMF using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/9ead6a16f1/w/

Also created an OOUI Demos page:
http://patchdemo.wmcloud.org/wikis/9ead6a16f1/w/build/ooui/demos

I've changed the way that we place menus so that we align them left instead. There's the risk that on especially narrow screens I might cause these to overflow, but, those would have to be about 300 pixels or less. In these screenshots I've used a width of 350px, which is the width of an iPhone mini.

Here's how the dropdown now looks, with the new behaviour: