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

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptWed, Oct 14, 11:49 PM
Reedy updated the task description. (Show Details)Thu, Oct 15, 12:50 AM

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.

Ineuw added a subscriber: Ineuw.Thu, Oct 15, 9:15 AM

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.

Bidgee added a subscriber: Bidgee.Thu, Oct 15, 9:41 AM

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

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%)").Thu, Oct 15, 9:53 AM
Aklapper triaged this task as High priority.Thu, Oct 15, 9:59 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.

Restricted Application added a project: Structured-Data-Backlog. · View Herald TranscriptThu, Oct 15, 9:59 AM

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)!

Jeff_G added a subscriber: Jeff_G.
Sailko added a subscriber: Sailko.Thu, Oct 15, 12:21 PM

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!

C1K98V added a subscriber: C1K98V.Thu, Oct 15, 4:16 PM


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.

matmarex claimed this task.Thu, Oct 15, 4:38 PM

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)

matmarex closed this task as Resolved.Thu, Oct 15, 7:11 PM

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

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!.Thu, Oct 15, 7:21 PM

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

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. 😁