Page MenuHomePhabricator

Not allowing linebreaks in Special:Contributions options box causes side-scrolling
Closed, ResolvedPublic


On en.wp (currently running 1.28.0-wmf.6 (rMWd50d367fb8ca)), the "Search for contributions" box where one selects username, namespaces, various checkboxes, etc has no breakable whitespace in each line of options. As a result, the widest line sets a mandatory width of that boxed part of the display. If my window is narrow, it overflows the window width. I'm using Firefox-47.0 on OS X, with Wikipedia's Vector skin.

There is a   between each checkbox and its label to keep them together (good!) and each checkbox+label is contained in a mw-input-with-label span that has white-space:nowrap in its CSS, which further reinforces no breaking anywhere in that chunk. But there seems to be no breakable whitespace between successive checkbox+label spans in a row.

Compare to Special:Whatchlist, where there is optional line-break possible between each checkbox+label in the "Hide:" row of options, which avoids overflowing my window width. If my window is narrow, that list of options simply wraps onto a second line.

See Also:
T138174: Space missing between "Namespace:" and dropdown on Special:Contributions

Event Timeline

A line break (\n) after each list item should provide a clean output allowing breaks.

That seems to work if I download the generatged page and manually edit the HTML.

Any progress? My screen is small, and that horizontal scrollbar always irritates me when I visit a contributions page...

This seems to be mostly resolved. Looking at 1.33.0-wmf.18 (rMW3456bc65792b), narrowing the window allows breaking between each option in a set but checkbox+option-text remains together. If I narrow the window so much that even one full option does not fit on a line, it side-scrolls because no breaking is allowed within the text of any one option. I'm not sure if that is good/bad, but given how extremely narrow one has to get to observe it, and that the alternative (allowing breaking within an option) is a worse problem, I would call this RESOLVED.