This can be fixed by changing the background image of .ve-ui-toolbar-bar to specify background-size: auto 100%; That does however affect the gradient in 1 row mode (size the background image is 2 rows high currently). So the background image might have to be regenerated for this.

Right now, when the browser is resized to narrow window OR at high zoom,all the toolbar buttons have a background and the contents of page does not show up behind the toolbar .But, the buttons on the first line is now overlapping with the Edit/Edit-beta buttons before user scrolls down the article.

Tested on MAC OS X 10.8.5 using firefox 20 and chrome 26.0.1410.65 on page:
https://en.wikipedia.org/w/index.php?title=World_War_II&veaction=edit

See the screenshots attached.

Created attachment 13767
all buttons having background and content not showing up

Attached:

Created attachment 13768
Toolbar buttons overlapping with Edit/Edit-beta button

Attached:

Marking as depending on bug 72159 because presumably we'd want to push groups into the catch-all group or something?

• Bug 70928 has been marked as a duplicate of this bug. ***

Something like https://gerrit.wikimedia.org/r/#/c/193282/ could possibly help here.

So the idea is that:

• When there is too little space, we should tighten the whitespace a bit (https://gerrit.wikimedia.org/r/#/c/193282/).
• When that doesn't help, all of the items that don't fit should be stuffed into a long dropdown list inserted at the end of the toolbar.

If this is a Q3 blocker, then I assume it should not depend on T74159: OOUI: Toolbar groups should support sub-groups as items (hierarchical, nested menus), and therefore the dropdown would just include all of the tools in one list rather than putting it in a hierarchical menu? At least until someone implements T74159, that is.

Change 193282 had a related patch set uploaded (by Bartosz Dziewoński):
Tighten toolbar whitespace on narrow displays

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

@KHammerstein & @Nirzar did you have a expanded version and compact version that we could use to show the extremes of how this should work, I assume we should leverage the usage and frequency information we found from the toolbar user testing to define the control collapse order.

From task summary:

all the buttons except those displayed on the last line are lacking a background

This affected only the Apex theme, and seems to have been fixed in the meantime – the gradient is correctly being stretched now.

In T52227#1079827, @Jaredzimmerman-WMF wrote:

@KHammerstein & @Nirzar did you have a expanded version and compact version that we could use to show the extremes of how this should work, I assume we should leverage the usage and frequency information we found from the toolbar user testing to define the control collapse order.

Other editors that implement this behavior just fold items from the end of the toolbar; I think that will be the least surprising for users. Perhaps we should place the most frequently used items at the beginning?

Here are screenshot of the whitespace tightening I'm working on above. I have not implemented it for MediaWiki theme yet, but it's going to look pretty much the same, sans the gradients and shadows.

"Wide" configuration:

How much actual space does this save for VE-MW?

Wide:

Narrow:

(It mostly cooperates with Vector's narrow display styles, as you can see.)

Is there a particular reason we don't make the narrower styling the default?

Yeah, the wide one looks better. Especially in the MediaWiki theme, where there are no separators or frames on the buttons and therefore we're forced to separate them with whitespace. (Apex has frames on hover, at least.)

Fair.

Change 195047 had a related patch set uploaded (by Bartosz Dziewoński):
ve.ui.Toolbar: Fix up onWindowResize to call parent method

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

Change 195049 had a related patch set uploaded (by Bartosz Dziewoński):
ve.init.mw.ViewPageTarget: Recalculate toolbar sizes when adding "Save" button

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

Change 193282 merged by jenkins-bot:
Toolbar: Tighten whitespace on narrow displays

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

Keeping open for the other half (based on T74159: OOUI: Toolbar groups should support sub-groups as items (hierarchical, nested menus)).

We can solve this problem by making VE toolbar responsive - here are more details about it with mockups

Change 195049 merged by jenkins-bot:
ve.init.mw.ViewPageTarget: Recalculate toolbar sizes when adding "Save" button

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

Okay, so I this bug mostly turned into "Make the toolbar narrower when the window is narrow", rather than what the current title says ("Toolbar should collapse items rather than span multiple lines when the window is narrow (responsive layout)"). Let's rename and close it, and continue with making the responsive behavior better on T92315.

Change 196305 had a related patch set uploaded (by Jforrester):
Update OOjs UI to v0.9.1

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

Change 195047 abandoned by Jforrester:
ve.ui.Toolbar: Fix up onWindowResize to call parent method

Reason:
Squashed into I936ea56e1c.

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

Change 196305 merged by jenkins-bot:
Update OOjs UI to v0.9.1

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