Page MenuHomePhabricator

Headings of sections on "Gadgets" tab on Special:Preferences display escaped HTML after OOUI conversion
Closed, ResolvedPublic

Description

https://imgur.com/a/1QOFF ­— links are broken, for no apparent reason there is a lot of space on the right and text wraps in the middle of the screen. It is does not take to be a designer to say that it is a regress.

Link: https://en.wikisource.org/wiki/Special:Preferences#mw-prefsection-gadgets

Event Timeline

Base created this task.Nov 30 2017, 8:41 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 30 2017, 8:41 AM
Base added a project: Wikisource.

As the screenshot is from enws, also adding Wikisource.

and some wikilinks are broken in heading lines

https://en.wikisource.org/wiki/Special:Gadgets

this OOjs is such a whitespace adder in sooooo many places. :-(

For future reference, links are welcome that allow reproducing. In this case, https://en.wikisource.org/wiki/Special:Preferences#mw-prefsection-gadgets so others don't have to type that in manually after looking at the provided screenshot.

links are broken

Where exactly? Please provide the specific text to look for at that page, so others don't have to guess what is meant.

there is a lot of space on the right and text wraps in the middle of the screen.

That's because of max-width: 50em; defined in oojs-ui-core.styles.

Task unrelated to OOjs hence removing OOjs.

As the screenshot is from enws, also adding Wikisource.

Removing Wikisource. See its project description: "Please do not report tasks under this project if the task is not actually specific to Wikisource but only because you found this problem on Wikisource." Maybe "links are broken" turns out to be a Wikisource-only problem, but impossible to say yet because missing steps to reproduce.

Base added a comment.EditedNov 30 2017, 11:40 AM

For future reference, links are welcome that allow reproducing. In this case, https://en.wikisource.org/wiki/Special:Preferences#mw-prefsection-gadgets so others don't have to type that in manually after looking at the provided screenshot.

It would really not harm for the devs to check all of the Special:Preferences to find what is on the Screenshot (though it is clear which tab is open) as they apparently never properly did it before. At least unfortunately I have a strong assuming bad faith feeling like this I cannot cope with.

Where exactly? Please provide the specific text to look for at that page, so others don't have to guess what is meant.

It is obvious, unless you are using a screenreader it is impossible to miss raw HTML instead of links.

That's because of max-width: 50em; defined in oojs-ui-core.styles.

Cool, but that is obviously the problem. Basically absolutely all software problems are because something is defined as something in somewhere.


@Aklapper, In general, when I am working in a project, routinely find that I was given an uncalled software update, find it faulty and do a favour to developers by reporting what they should have found themselves before deploying their changes to production, I do not expect to also be demanded of to follow a more rigid reporting protocol instead. I expect a fix and a gratitude for the report. While I respect what you are doing and it is literally your job to take care of Phabricator tasks, some your comments make me feel very unwelcome and angry because you are calling for me to spend even more my time describing an obvious problem caused by an issue than I have volunteered to contribute. I am not a best person to be giving attitude tips, and having experienced being on the other side for a short while I do not envy you, but still I cannot help being already annoyed by people braking software I use without any apparent improvement (OOjs even without the reported stuff works slower and generally makes work less smooth being more machine and broadband demanding), when feeling like that being demanded to spend my time basically doing the job of people who are payed to do it is literally the last thing I want to experience. I am not a WMF Staff QA.

TheDJ added a subscriber: TheDJ.EditedNov 30 2017, 3:24 PM

@Base

It would really not harm for the devs to check all of the Special:Preferences

Well since you didn't specify initially.. I guess you expected one of us to check on all 950'ish wikis that we support ?
Lemme start with one:

No broken links... I'll let you know when I checked the other 950....

It is obvious, unless you are using a screenreader it is impossible to miss raw HTML instead of links.

Yeah super obvious.... if there was not a variance of 950 wikis * 200 or so user specific settings....

While criticism is welcome, relatively speaking the foundation is SEVERELY understaffed to meet the technical goals to the level you seem to expect. The foundation is an NGO, not a commercial organisation and as such many parts are a collaborative effort. You do not have to answer, but you then you also should not expect a speedy analyses, let alone a fix. That's what commercial organisations are for, so you can refuse to pay them and take your business to the competition.
Developers (staff and volunteers alike) balance, as delicate as possible, the requests of the users, the goals for the future, quality and the resources available, with the full understanding that it is an impossible to achieve set of goals, similarly to aspiring to have all Wikipedia articles be featured articles. We fail at that all the time, every single day and are fully aware of it. It's part of how all of this is possible in the first place.

with kindness, a volunteer

matmarex updated the task description. (Show Details)Nov 30 2017, 4:00 PM
TheDJ updated the task description. (Show Details)Nov 30 2017, 4:03 PM
matmarex added a subscriber: matmarex.EditedNov 30 2017, 4:35 PM

@Base @Billinghurst I am sorry about the broken links, that's my mistake. I didn't realize formatting was allowed in the headings of gadgets' sections (there isn't any on the wikis I regularly use). I'll get it fixed today. (I think that is the only place where this occurs?)

We use the 50em width for all OOUI forms, it usually works well to prevent things like dropdowns and text fields from being insanely wide, although perhaps it's disputable whether it helps in the "Gadgets" sections of preferences (I think it looks just fine in all other ones), it looks especially silly because the into text of that sections is not wrapped for some reason. Can you file another task about this? (So that we can pretend the angry comments from everyone on this task did not happen…)

Change 394333 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/core@master] HTMLMultiSelectField: Allow formatting in section headings in OOUI mode

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

Now I am confused, I pasted an image of English Wikisource broken links above. Subject headers used within Gadgets page. The Special:Gadgets page shows proper links, previously the Special:Preferences gadgets provided proper links, since the update to Oojs there are these broken links. [Apologies for not pasting the actual url, it was a dash out the door job.]

matmarex renamed this task from Special:Preferences looks broken after being defiled by OOjs to Headings of sections on "Gadgets" tab on Special:Preferences display escaped HTML after being defiled by OOjs UI.Nov 30 2017, 4:39 PM
matmarex removed projects: Design, OOUI.

I'm not sure what's confusing about that? Special:Gadgets and the "Gadgets" tab on Special:Preferences are separate things. Only the latter is currently broken. The patch I submitted above fixes it.

that was edit conflict

I'm not sure what's confusing about that? Special:Gadgets and the "Gadgets" tab on Special:Preferences are separate things. Only the latter is currently broken. The patch I submitted above fixes it.

@Base @Billinghurst I am sorry about the broken links, that's my mistake. I didn't realize formatting was allowed in the headings of gadgets' sections (there isn't any on the wikis I regularly use). I'll get it fixed today. (I think that is the only place where this occurs?)
We use the 50em width for all OOUI forms, it usually works well to prevent things like dropdowns and text fields from being insanely wide, although perhaps it's disputable whether it helps in the "Gadgets" sections of preferences (I think it looks just fine in all other ones), it looks especially silly because the into text of that sections is not wrapped for some reason. Can you file another task about this? (So that we can pretend the angry comments from everyone on this task did not happen…)

done at T181733

Jdforrester-WMF renamed this task from Headings of sections on "Gadgets" tab on Special:Preferences display escaped HTML after being defiled by OOjs UI to Headings of sections on "Gadgets" tab on Special:Preferences display escaped HTML after OOUI conversion.Nov 30 2017, 4:57 PM
Jdforrester-WMF triaged this task as Normal priority.

Change 394333 merged by jenkins-bot:
[mediawiki/core@master] HTMLMultiSelectField: Allow formatting in section headings in OOUI mode

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

Change 394339 had a related patch set uploaded (by Jforrester; owner: Bartosz Dziewoński):
[mediawiki/core@wmf/1.31.0-wmf.10] HTMLMultiSelectField: Allow formatting in section headings in OOUI mode

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

matmarex claimed this task.Nov 30 2017, 5:09 PM
matmarex removed a project: Patch-For-Review.

Change 394339 merged by jenkins-bot:
[mediawiki/core@wmf/1.31.0-wmf.10] HTMLMultiSelectField: Allow formatting in section headings in OOUI mode

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

Mentioned in SAL (#wikimedia-operations) [2017-11-30T19:20:40Z] <thcipriani@tin> Synchronized php-1.31.0-wmf.10/includes/htmlform/fields/HTMLMultiSelectField.php: SWAT: [[gerrit:394339|HTMLMultiSelectField: Allow formatting in section headings in OOUI mode]] T181698 (duration: 00m 49s)

matmarex closed this task as Resolved.Nov 30 2017, 7:21 PM

Fixed and deployed.