Page MenuHomePhabricator

Block messages reveal the contents behind the popup on small screen sizes
Open, In Progress, Needs TriagePublic

Description

After the fix for T387119: Block messages don't appear correctly on mobile, when opening the popup on small screen sizes, a region of the popup reveals the content behind it.

trasparent-bg.png (1×1 px, 257 KB)

A priori, this can be fixed by adding the following rule to BlockMessageDetails.less

@media screen and ( max-height: 460px ) {
	.drawer-container .block-message {
		// Prevents a problem observed on very small screen sizes (heights less
		// than 460px) where the height of the top white part becomes so small
		// that its contents overflow, making the popup to show a transparent
		// region between the main message area and the div showing the reason
		// for the block, thus revealing the contents behind the popup.
		max-height: none !important;
	}
}

See also https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1129332/comment/4ca764aa_e3e532ba/ & https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1129332/44..46 for a fix

Browser:

Chromium 131.0.6778.204 (Official Build) built on Ubuntu 24.04.1 LTS (64-bit)
Revision 52183f9e99a61056f9b78535f53d256f1516f2a0-refs/branch-heads/6778_155@{#7}
OS Linux
JavaScript V8 13.1.201.19
User Agent Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

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

  • Create a block
  • Click edit icon
  • Click see more
  • Shrink browser to 433 x 385

What happens?:

What should have happened instead?:

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

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

Easiest way to show a block is to edit is to edit parseBlockInfo and getLoadingPromise in EditorOVerlayBase

Promise.resolve( `ASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasa
			ASjadsjajasa
			ASjadsjajasa
			ASjadsjajasa
			ASjadsjajasa
			
			ASjadsjajasa
			ASjadsjajasa
			ASjadsjajasa`)
	/**
	 * Get a promise that is resolved when the editor data has loaded,
	 * or rejected when we're refusing to load the editor because the user is blocked.
	 *
	 * @return {jQuery.Promise}
	 */
	getLoadingPromise() {
		return this.dataPromise.then( ( result ) => {
			// check if user is blocked
			result = {
				blockinfo: {
					blockpartial: false,
					blocknocreate: true,
					blockanononly: true,
					blockedby: 'Foo',
					blockreason: `ASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasaASjadsjajasa
ASjadsjajasa
ASjadsjajasa
ASjadsjajasa
ASjadsjajasa

ASjadsjajasa
ASjadsjajasa
ASjadsjajasa`,
					blockexpiry: 1000,
					blockexpiryformatted: new Date(),
					blockexpiryrelative: 1000,
					blockid: 1000
				}
			};
			if ( result && result.blockinfo ) {
				const block = parseBlockInfo( result.blockinfo ),
					message = blockMessageDrawer( block );
				return util.Deferred().reject( message );
			}
			return result;
		} );
	}

Event Timeline

Reedy renamed this task from Block messages reveal the contents behind the popup on small scren sizes to Block messages reveal the contents behind the popup on small screen sizes.Apr 2 2025, 3:27 PM

The crux of the issue here is that drawer components have a maximum height of 50%. Your component is bigger than that and not really what the drawer was originally envisioned as doing. Your block reason element alone specifies a height of 30vh. When the height of the viewport is 390px, that means the drawer has a maximum height of 195px and 117px for the reason alone.

The gap you are seeing relates to the bottom margins on .block-message-item and .block-message-data.

Personally, I would resolve this by disabling the max-height for all .drawer.block-message elements since it does not seem to be a conventional drawer and it seems fine for this one to take up the whole height of the screen if necessary given it interrupts an action. I would say do this for all media queries to make it easier to maintain. Alternatively you could add overflow: scroll; to the component

As far as I know, it wasn't: This ticket was split from T387119 during the code review, as per our prior discussion in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1129332/50..52/resources/mobile.editor.overlay/BlockMessageDetails.less#b79 and I've not went back to this yet.

However, it's been a while since I filed the ticket, and I'm not sure if this is still reproducible.

Change #1146969 had a related patch set uploaded (by Máté Szabó; author: Máté Szabó):

[operations/mediawiki-config@master] Update IPInfo access levels

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

Verified this is still happening in an actual Android device

image.png (785×1 px, 1 MB)

Change #1151671 had a related patch set uploaded (by Harroyo-wmf; author: Harroyo-wmf):

[mediawiki/extensions/MobileFrontend@master] popup: Make the popup cover the whole screen height for small screen heights

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

Change #1151671 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] popup: Make the popup cover the whole screen height for small screens

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

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1151671 was merged, and the popup should not be showing a transparent region between the reason and the gray details area on small screen sizes anymore. Moving this to QA.

Change #1163730 had a related patch set uploaded (by Harroyo-wmf; author: Harroyo-wmf):

[mediawiki/extensions/MobileFrontend@master] dialog: Make the whole dialog scrollable for very small screen heights

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

Uploaded an additional patch to make the full dialog scrollable on very small screen heights, since on those it may happen that the main dialog contents plus the reason text hide the "OK" button outside of the screen, even after the last fix that makes the reason text region scrollable: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1163730. This was something raised during QA.

I'm moving the ticket back to Needs Review

I think this can be considered a Trust and Safety Product Team or editing team bug going forward provided the change is localized to the editor (e.g. not global styles that apply to all drawers).

I am in the process of defining ownership in MobileFrontend to make this clearer going forward T403659: MobileFrontend should have an OWNERS.md