Page MenuHomePhabricator

Text on UploadWizard's "Describe" page is too narrow (due to .mwe-upwiz-data defining "width: calc(-132.5%)")
Closed, ResolvedPublic

Description

some css issue with FF 81 and current chrome
should be reproducible with any image.

Go to https://commons.wikimedia.org/wiki/Special:UploadWizard, navigate through the wizard to the "describe" step, where you will see the labels and text boxes are very narrow

Event Timeline

Has been reported with various browsers, see https://commons.wikimedia.org/wiki/Commons:Help_desk#Upload_Wizard_seems_to_be_broken. I experience this myself with Palemoon/Windows 7. Needs to be fixed asap in view of WLM ongoing.

I am using Google Android with the Ecosia browser and have the exact same issue, both on mobile mode and desktop mode. Please see https://phabricator.wikimedia.org/T265578 for screenshots, my menus are even more narrow.

Same issue as well, using "Chrome Version 85.0.4183.121 (Official Build) (64-bit)" on MacOS 10.15.6 (19G2021).

Screen Shot 2020-10-15 at 8.30.42 pm.png (1×2 px, 629 KB)

Screen Shot 2020-10-15 at 8.35.30 pm.png (1×1 px, 190 KB)

Screen Shot 2020-10-15 at 8.33.25 pm.png (1×1 px, 128 KB)

Screen Shot 2020-10-15 at 8.36.05 pm.png (2×2 px, 523 KB)

Aklapper renamed this task from Upload Wizard broken, describe form much too narrow to Text on UploadWizard's "Describe" page is too narrow (due to .mwe-upwiz-data defining "width: calc(-132.5%)").Oct 15 2020, 9:53 AM

https://phabricator.wikimedia.org/diffusion/EUWI/browse/master/resources/uploadWizard.less defines

#mwe-upwiz-stepdiv-details .mwe-upwiz-data {
		/* 230px + 2.5em is width of thumbnail on the left */
		width: calc( 100% - 230px - 2.5em );
	}

but code has not changed for two years.
Latest conversion from CSS to LESS in 104c59d76ba3931eabe595e5f6c661e3b87f86a5 didn't change anything either.

Same issue in "Safari Version 14.0 (15610.1.28.1.9, 15610)". Though categories became a problem after adding three categories, the auto search went blank (screenshot attached)!

Screen Shot 2020-10-15 at 9.09.43 pm.png (1×1 px, 400 KB)

Screen Shot 2020-10-15 at 9.11.25 pm.png (754×844 px, 50 KB)

same issue on either Chrome of Firefox, no updates of browsers in between

Schadenfreude. Ich habe über Monate immer wieder danach verlangt, den Wizard erst mal zu reparieren, statt neue Funktionen hinzuzufügen. Mein Vorschlag bleibt derselbe: Den Wizard auf den Stand von vor 3 Jahren zurücksetzen, da ging es noch.

@C.Suthorn: Hi, please see and follow https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette where you can bring up meta-level discussions on priorities in general, as they are unrelated here (this task is about one specific software bug). Thanks for your understanding!

issue (1).png (1×1 px, 137 KB)

issue (2).png (1×1 px, 98 KB)

I'm using Chrome android mobile browser version 86.0.4240.99 I'm also getting the same issue since yesterday

https://phabricator.wikimedia.org/diffusion/EUWI/browse/master/resources/uploadWizard.less defines

#mwe-upwiz-stepdiv-details .mwe-upwiz-data {
		/* 230px + 2.5em is width of thumbnail on the left */
		width: calc( 100% - 230px - 2.5em );
	}

but code has not changed for two years.
Latest conversion from CSS to LESS in 104c59d76ba3931eabe595e5f6c661e3b87f86a5 didn't change anything either.

This would be caused by the conversion to LESS. It calculates that value instead of leaving it unchanged for CSS, and it ignores the units, so we get 100 - 230 - 2.5 = -132.5.

And there are other places in UploadWizard that have a workaround for this problem, we just need to do the same here:

extensions/UploadWizard/resources/metadata/uw.MetadataPage.less:
   15: 			width: ~'calc( 100% - 10px - @{thumbnail-width} )'; // ~ is required to disable LESS auto-calculation...

extensions/UploadWizard/resources/ui/steps/uw.ui.Metadata.less:
   27: 			width: ~'calc( @{menu-width} - 3em )';
   46: 		width: ~'calc( 100% - @{menu-width} )'; // ~ is required to disable LESS auto-calculation...

I'll submit a patch.

Change 634290 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/UploadWizard@master] Work around LESS calculating calc() values wrong

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

Change 634252 had a related patch set uploaded (by Jforrester; owner: Bartosz Dziewoński):
[mediawiki/extensions/UploadWizard@wmf/1.36.0-wmf.13] Work around LESS calculating calc() values wrong

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

Change 634290 merged by jenkins-bot:
[mediawiki/extensions/UploadWizard@master] Work around LESS calculating calc() values wrong

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

Thanks for the patch! Does it mean that it will be applied only on October 20? Is there a way to fix the bug earlier? Thousands of people are using Upload Wizard now due to the ongoing Wiki Loves Monuments...

We are backporting it today (right now, in fact).

Change 634252 merged by jenkins-bot:
[mediawiki/extensions/UploadWizard@wmf/1.36.0-wmf.13] Work around LESS calculating calc() values wrong

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

Mentioned in SAL (#wikimedia-operations) [2020-10-15T19:04:18Z] <catrope@deploy1001> Synchronized php-1.36.0-wmf.13/extensions/UploadWizard/: Work around LESS calculating calc() values wrong (T265560) (duration: 02m 07s)

Fixed and backported. The "Describe" step on https://commons.wikimedia.org/wiki/Special:UploadWizard looks normal to me again.

image.png (2×3 px, 380 KB)

I also filed T265650: Enable strict units in LESS, which should prevent similar mistakes in the future, but it will take some work to do that and I'm not sure if or when that can happen.

matmarex raised the priority of this task from High to Unbreak Now!.Oct 15 2020, 7:21 PM

Screenshot_20201016-083512.png (1×1 px, 83 KB)

Not sure if the bug fix is deployed yet, but I'm still experiencing this bug on my side (Ecosia 78.0. 3904.96). 😕

Screenshot_20201016-102009.png (1×1 px, 377 KB)

It is ONLY fixed in desktop mode, while using mobile mode it still displays the initial error.

@DonTrung: No, this is also fixed on mobile. Please clear your cache.

My bad, it's fixed on mobile too now, just found it odd that it displayed differently on desktop and mobile as I had previously attempted both, but the issue seems fully resolved on my side too.

Thank you @matmarex for your work. 😁