Page MenuHomePhabricator

Sidepanel flows into Wikpedia article content
Closed, DuplicatePublicBUG REPORT

Assigned To
None
Authored By
Prototyperspective
Jul 22 2022, 10:42 AM
Referenced Files
F35330400: image.png
Jul 22 2022, 6:24 PM
F35330398: image.png
Jul 22 2022, 6:24 PM
F35330311: Screenshot from 2022-07-22 18-01-23.png
Jul 22 2022, 4:05 PM
F35330312: Screenshot from 2022-07-22 18-01-17.png
Jul 22 2022, 4:05 PM
F35330080: wppanel.png
Jul 22 2022, 10:42 AM

Description

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

  • Open any Wikipedia article in Firefox at standard 100% zoom

What happens?:
Since today, 22 July the left side panel flows into the content.

What should have happened instead?:
It should not to do that. Just like the TOC should not be replaced by something that is worse than the thing demonstrated before and I shouldn't need to create this issue because it's an obvious bug.

Software version (skip for WMF-hosted wikis like Wikipedia):

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

It happens with all of the many zoom-levels and all browser window widths and all Wikipedia articles that I tried.

wppanel.png (1×1 px, 538 KB)

Event Timeline

Aklapper changed the task status from Open to Stalled.Jul 22 2022, 4:05 PM

Cannot reproduce in Firefox 102.0 on Linux. What's the exact width?
Does that also happen in safemode? See https://www.mediawiki.org/wiki/Help:Locating_broken_scripts

Screenshot from 2022-07-22 18-01-17.png (954×1 px, 301 KB)

Screenshot from 2022-07-22 18-01-23.png (954×998 px, 83 KB)

I'm seeing a very simliar bug, at 1000px, it is fine:

image.png (539×1 px, 52 KB)

at 999px the sidebar become full width and stacks above the content:

image.png (394×1 px, 27 KB)

@Aklapper - your screen shot is similar, should that be a separate bug - I can't see why the sidebar should ever behave like that (stretch to full width and stack).?

Split the "full width sidebar" problem to T313611

I'm seeing a very simliar bug, at 1000px

For the records, that is NOT what this ticket is about at all. :)

It happens with all widths and zoom levels that I tried with (earlier Firefox than 102) and also when I add ?safemode=1 to the url. Restarting the browser didn't help. I never had this problem until 22 July and it's very annoying as it hides parts of all articles. What did you change on 21/22 July?

Prototyperspective changed the task status from Stalled to Open.Jul 26 2022, 8:13 AM
Aklapper changed the task status from Open to Stalled.Jul 26 2022, 8:46 AM

It happens with all widths and zoom levels

Does that mean if you use a, say, 600px width window that the sidebar is not displayed full width, above the actual content? Please be exact to avoid misunderstandings.

and also when I add ?safemode=1 to the url.

Please provide a full complete URL plus a screenshot showing the content of that very URL and including the browser address bar. Thanks!

What did you change on 21/22 July?

https://www.mediawiki.org/wiki/MediaWiki_1.39/wmf.21/Changelog

I wonder if this could be the same as T313817: Increased font-size (>=20px) causes TOC to overlap text now that I found that ticket.
Any particular settings in Firefox under "Settings > General > Language and Appearance > Fonts"? Still trying to identify the root cause.

Jdlrobson subscribed.

at 999px the sidebar become full width and stacks above the content:

This is working as intended (for now). The FAQ has some details on how we hope to change this in future.

wonder if this could be the same as T313817: [Chrome bug] Increased font-size causes TOC to overlap text now that I found that ticket.

Yes these bugs are the same.

I don't remember changing the font-size and until recently this wasn't a problem. Moreover, in these settings I have "Allow pages to choose their own fonts, instead of your selections above" checked.

I can confirm that after changing it to a font-size < 20 makes the problem disappear.

This bug should be prevented and/or detected with testing before moving the respective change to production and I don't know how this could happen accidentally. Please fix the bug asap.

More contributed browser tests for random web browser features are welcome.

We have extensive browser tests and visual regression tests but those only cover the browser defaults for a small subset of browsers (which is in about 90% of cases enough). This is something we should have picked up in code review but accidents happen. We are working on a fix as we speak.