Page MenuHomePhabricator

Wiki pages are very wide in Monobook for logged in users
Closed, ResolvedPublic

Description

Hello,

Since today, there appears to be an issue with the styling of several wikis, including enwiki and meta. Even though all of the content of the wiki page is visible on the screen normally, the actual page is exceptionally wide in the browser. There is a horizontal scrollbar visible, which scrolls the entire page. This occurs even though there is no visible content "right" of the page.

The actual HTML <body> element is showing as 1903px x 997px in Chrome Dev Tools, however, the actual page is some thousands of pixels wide. There is no obvious culprit in the HTML that is causing this. This occurs on all pages, so it isn't a formatting bug in the wikicode, and it occurs on both Firefox and Chrome. My default skin is Monobook.

This is creating a bad UI/UX combination, as the user is being led to believe that there is additional content to the right of the page, even when there is not.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Xaosflux updated the task description. (Show Details)Jun 26 2019, 3:41 AM

Mention: link to T226503 - which is noted as causing this new problem.

Isarra added a subscriber: Isarra.Jun 26 2019, 3:57 AM

Perhaps we can take a look in the morning at maybe just killing all the special skinstyles in Echo for the non-minerva skins (Minerva is really the only one not just doing basically the exact same thing as the rest) and doing what skin-example does. And all the other wikimedia-deployed skins have inline or inline-like personal tools, so it really shouldn't be this complicated...

Isarra added a subscriber: ashley.Jun 26 2019, 3:57 AM
Aklapper renamed this task from All wikis are very wide in monobook for logged in users to Wiki pages are very wide in Monobook for logged in users.Jun 26 2019, 8:04 AM

It was previously extended 10000px to the left, and with the change, it's not 10000px to the right, correct?

Perhaps @Catrope or @MarcoAurelio can explain it better? My understanding is that a recent change broke the notifications, and rather then rolling it back an additional change was put on top that caused this new issue.

Perhaps @Catrope or @MarcoAurelio can explain it better? My understanding is that a recent change broke the notifications, and rather then rolling it back an additional change was put on top that caused this new issue.

Correct, it changed the existing issue in MonoBook to be more apparent, seemingly.

I don't recall there being an actual user experience issue presenting before though - was there an actual previous user interface problem? (Ticket number?)

IIUC the gain is using the centralized OOUI icons instead of shipping separate icons (which might get out of sync) in Notifications in T139779.

@Aklapper compared to the user experience of presenting that there may or may not be some content just off the screen on every page, that is a major UX loss

@Aklapper something "might get out of sync" vs something is actually presenting worse then it was before feels like a loss to me. Unless monobook is going to officially be discontinued, it (along with all skins) should be part of QA tests to prevent these sorts of problems.

Change 519306 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Echo@master] Follow-up ea856105f2b: fix horizontal scrollbars in Monobook

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

@Aklapper something "might get out of sync" vs something is actually presenting worse then it was before feels like a loss to me. Unless monobook is going to officially be discontinued, it (along with all skins) should be part of QA tests to prevent these sorts of problems.

Full MonoBook support was officially discontinued in April 2013 (recognising reality since 2010). See my announcement then. They are kept on in production because volunteer developers have undertaken to keep them up-to-date.

Change 519306 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Follow-up ea856105f2b: fix horizontal scrollbars in Monobook

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

Change 519308 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Echo@wmf/1.34.0-wmf.11] Follow-up ea856105f2b: fix horizontal scrollbars in Monobook

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

Change 519309 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Echo@wmf/1.34.0-wmf.10] Follow-up ea856105f2b: fix horizontal scrollbars in Monobook

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

Change 519308 merged by jenkins-bot:
[mediawiki/extensions/Echo@wmf/1.34.0-wmf.11] Follow-up ea856105f2b: fix horizontal scrollbars in Monobook

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

Change 519309 merged by jenkins-bot:
[mediawiki/extensions/Echo@wmf/1.34.0-wmf.10] Follow-up ea856105f2b: fix horizontal scrollbars in Monobook

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

Mentioned in SAL (#wikimedia-operations) [2019-06-26T23:38:19Z] <catrope@deploy1001> Synchronized php-1.34.0-wmf.11/extensions/Echo/modules/nojs/mw.echo.badge.monobook.less: Fix horizontal scrollbars in Monobook (T226594) (duration: 00m 57s)

Mentioned in SAL (#wikimedia-operations) [2019-06-26T23:39:39Z] <catrope@deploy1001> Synchronized php-1.34.0-wmf.10/extensions/Echo/modules/nojs/mw.echo.badge.monobook.less: Fix horizontal scrollbars in Monobook (T226594) (duration: 00m 55s)

Catrope closed this task as Resolved.Jun 26 2019, 11:43 PM
Catrope claimed this task.

This is now fixed on all production wikis. Apologies for the disruption.

Full MonoBook support was officially discontinued in April 2013 (recognising reality since 2010). See my announcement then. They are kept on in production because volunteer developers have undertaken to keep them up-to-date.

This is a bit misleading, I think. For the most part these skins have indeed been supported, as evidenced by all the issues we are running into now - the only reason these changes were able to break one specific skin, and only that specific skin, was precisely because the WMF developers did include explicit, specific, MonoBook support in Echo itself. And while that support perhaps had some flaws in its implementation (in particular that it was so different from the other skins), working to support what we have currently as efficiently and elegantly as possible is really the only way we can possibly hope to effectively support interoperability with whatever future products we make, as well.

...which was the other thing that caused all this: getting rid of the Echo-specific icons in favour of a more widely-used implementation, which likewise should help support better compatibility and reduce maintenance needs in the long term. Basically, we're all working on it. Sometimes it doesn't quite work out, but eh.

MaxBioHazard reopened this task as Open.Jun 27 2019, 3:02 AM

Now my userpage link overlaps by notifications link.

All of the clicks are off there, going from right to left, the "notices" clickable area seems to start right at the inbox icon, but continues until halfway through the bell icon; then the 'alerts' one begins and continues for about double the width of the bell icon to the left (overlapping the username display)

In the modern skin the notification icons are even worse, especially the 'inbox' one:

Yes, the clickable areas overlapping is a known issue, it's T161302. It was fixed before, but now it's back again (in Monobook only). I'll look into ways to fix this tomorrow (especially to make clicks on other links like the user page link work correctly), but this has proven tricky so far.

Xaosflux added a comment.EditedJun 27 2019, 3:20 AM

The more I look the more problem I can see with these in various skins, in CologneBlue they are overlapping the vertical area

Please let us know if there should be distinct phab tickets open for each of the skin's issues

Pruem added a subscriber: Pruem.Jun 27 2019, 3:34 AM

This goes to show the importance of testing. The uninformed user can easily construe such hiccups as being intentional trolling on behalf of WMF employees.

I would also like to point out that there are numerous users out there who would rather leave Wikimedia projects altogether than switch to vector, no matter what the WMF decides. It's up to them (the WMF) to deal with it.

Isarra added a comment.EditedJun 27 2019, 4:44 AM

The cologneblue issue isn't new - I think it's always been like that.

Filed T226684 about cleaning up the echo skinstyles in general for all deployed skins - this should properly fix all these issues, but shouldn't necessarily block any more immediate fixes in the meantime, if we're sure they're not going to do anything else weird. This has been a wild ride.

@Pruem: If random folks assume random bad faith, so be it. Bugs happen. Testing too. Also see mw.org/Bug_management/Development_prioritization.
Discussing that is off-topic here in this very task though... See mw.org/Bug_management/Phabricator_etiquette where to bring up meta-level topics.

The more I look the more problem I can see with these in various skins, in CologneBlue they are overlapping the vertical area

@Xaosflux: For CologneBlue, that has been the case for years (literally!) and is not a recent regression. See e.g. T141944 from 2016.
It probably tells how maintained that skin is.

Pruem added a comment.EditedJun 27 2019, 9:45 AM

@Aklapper: Xaosflux has summed it up before me. I was just curious what would be the difference between "no full support" and "no support". Carrying wikipolitics on the backs of Wiki users (and volunteer developers) will not cut it, at least for me.

@Pruem: Hmm, maybe I misunderstood your previous comment then. In that case, I apologize.

TheDJ added a subscriber: TheDJ.EditedJun 27 2019, 1:12 PM

what would be the difference between "no full support" and "no support".

Not really defined for skins, but I'd say it's like with older versions of Internet Explorer. It's dead but has users, no one who is doing the work is using it, it's not being tested, but if some basic functionality becomes impossible we will eventually take a look (reactive) instead of saying "drop dead" (denial of service). If some advanced functionality breaks, we might decide to switch the functionality off for that case and fallback to 'basic' functionality.

All opposed to full production quality, which is proactive of course, and assuming that no matter the level of support you provide there can always be bugs, unforeseen issues etc etc.

Having said that, it might be good idea to draw up a support matrix for skins, much as we have for browsers.

Oh and because apparently I have to state things like this these days.. That's my opinion as a volunteer, i'm not an employee of the WMF and it is not an official policy.

Pruem added a comment.Jun 27 2019, 1:40 PM

It is just that it's a little confusing - a company shipping a piece of software yet not taking any responsbility for it. I would prefer it if there was a clear communication or a timetable for a phaseout so that end users would know when, how and where their own initiative was required. Leaving things to rot is not my idea of what I expect from a service provider.

TheDJ added a comment.Jun 27 2019, 2:14 PM

This is not a company, it's a highly underfunded development department of an NGO with a couple of extra volunteers on the side, topped off with a customer base that is gigantic and will burn the place down if they don't like something ;)

Pruem added a comment.Jun 27 2019, 2:32 PM

It would be (mildly) tragic if that NGO (read multi-million dollar Corporation) was so far removed from its original purpose as to foolishly blunder over some stupid badge icons.

TheDJ added a comment.Jun 27 2019, 2:34 PM

No, see it like this.. when there are 25000 icons locations, you can only focus on 2000 or so (regardless of how little or stupid they are). But this is getting a bit off topic. let's shut this discussion down.

There's an NGO that does mw skins? Have we reached out to them in order to collaborate on these things?

Serious note on the alignment problems @Catrope please see (https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=903776666#Excessive_width_on_monobook) where some suggested local fixes have been getting worked on. I haven't tested and am not ready to move these to site css's - especially if this has an 'upstream' fix coming.

Change 519571 had a related patch set uploaded (by Isarra; owner: Isarra):
[mediawiki/skins/CologneBlue@master] Put echo badges on a single line

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

Change 519571 merged by jenkins-bot:
[mediawiki/skins/CologneBlue@master] Put echo badges on a single line

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

Change 519587 had a related patch set uploaded (by Isarra; owner: Isarra):
[mediawiki/skins/MonoBook@master] Echo compatibility: use float: right instead of text-align: right on personal tools

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

Change 519591 had a related patch set uploaded (by Isarra; owner: Isarra):
[mediawiki/extensions/Echo@master] MonoBook: Remove outdated skin styles and clean up some

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

Change 519587 merged by jenkins-bot:
[mediawiki/skins/MonoBook@master] Echo compatibility: use float: right instead of text-align: right on personal tools

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

Change 519591 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] MonoBook: Remove outdated skin styles and clean up some

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

When fix will be released? Still broken now.

@MaxBioHazard: Regarding WMF sites: If nobody volunteers to SWAT-deploy the merged patch, then the default deploy cycle applies (linked from Deployments).

Can you tell me a certain date? Your links contains many data, but no information about when this fix will be released.

@MaxBioHazard: Nobody can, because it depends on the website (and what "released" means, I assume you mean deployed as the code change is already released). Tuesday or Wednesday or Thursday. See https://tools.wmflabs.org/versions/ and https://wikitech.wikimedia.org/wiki/Deployments/One_week

Isarra closed this task as Resolved.Jun 30 2019, 9:36 PM

^ Assuming nothing else goes wrong with anything else and blocks the train, of course. Because that sometimes happens too!

Anyway, this specific task has totally been resolved. The other issues have their own tasks that may or may not still be open, though.

Thanks @Isarra for all your patches!

Since there's no deployment train this week, I'm going to schedule these patches for a SWAT this week, after a quick review+test.

Change 520325 had a related patch set uploaded (by Catrope; owner: Isarra):
[mediawiki/skins/MonoBook@wmf/1.34.0-wmf.11] Echo compatibility: use float: right instead of text-align: right on personal tools

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

Change 520326 had a related patch set uploaded (by Catrope; owner: Isarra):
[mediawiki/extensions/Echo@wmf/1.34.0-wmf.11] MonoBook: Remove outdated skin styles and clean up some

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

Scheduled for deployment at in the 23:00-00:00 UTC window (about 45 minutes from now)

Change 520326 merged by jenkins-bot:
[mediawiki/extensions/Echo@wmf/1.34.0-wmf.11] MonoBook: Remove outdated skin styles and clean up some

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

Change 520325 merged by jenkins-bot:
[mediawiki/skins/MonoBook@wmf/1.34.0-wmf.11] Echo compatibility: use float: right instead of text-align: right on personal tools

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

Mentioned in SAL (#wikimedia-operations) [2019-07-02T23:34:48Z] <catrope@deploy1001> Synchronized php-1.34.0-wmf.11/skins/MonoBook/: T226594 (duration: 00m 50s)

Mentioned in SAL (#wikimedia-operations) [2019-07-02T23:36:09Z] <catrope@deploy1001> Synchronized php-1.34.0-wmf.11/extensions/Echo/: T226594 (duration: 00m 51s)