Using Windows 10, latest Nightly.

Basically, when you open a menulist, usually if the list is not too long, it will be displayed horizonally instead of vertically. And not always.
If the list is too long, then for a split second it'll be displayed horizonally and then revert back to being displayed vertically.

This happens in the following UIs:

1. On the Bookmarks Toolbar, if you have a folder there and you click it
2. On the menu bar > Bookmarks or History

This happens on 2 different machines, both are not sharing the same addons so we can probably rule this out.
Nothing appears on the console when this happens.

I'm not sure what is the STR yet, thus unable to check regression range atm. This started about a week or two ago.

See attached.

Note that this doesn't reproduce 100% of the time.

Probably something with the XBL removal/conversion? Brian, can someone investigate this?

Alex said he'd take a look.

I recall seeing this in the wild once or twice, I even thought this is a new feature in Firefox design, it looked somewhat cool :) but it seems I cannot reproduce any longer. Any chance to double check, in case if something have magically fixed the issue over last week? Or any luck to come with reliable steps to reproduce?

(In reply to alexander :surkov (:asurkov) from comment #4)

I recall seeing this in the wild once or twice, I even thought this is a new feature in Firefox design, it looked somewhat cool :) but it seems I cannot reproduce any longer. Any chance to double check, in case if something have magically fixed the issue over last week? Or any luck to come with reliable steps to reproduce?

Sorry, I can still reproduce it on the latest Nightly :-(
Still no STR.

asking for regression-window, a culprit bug might give a hint on what's going on here, the most intriguing thing for sure is the bug seems to be intermittent, so it's more complicated that missing @orient attribute or something.

I can also reproduce the issue on Nightly71.0a1 Windows10.

Reproducible: almost 100% if Browser Toolbox was opened

Steps To Reproduce:

1. "Enable browser chrome and add-ons debugging toolbars" and "Enable remote debugging"

2. Enable Menu Bar or Bookmarks Toolbar with subfolders

3. Open Browser Toolbox (Ctrl+Alt+Shift+I)

4. Click "Bookmarks" in Menu Bar, subfolder etc...

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=94eaa02e0ea1725512893cd5139b1d200fcf4fdd&tochange=5e221240fc1d537da612973800bbe24efa50736b

Regressed by:
5e221240fc1d537da612973800bbe24efa50736b Brian Grinstead — Bug 1514926 - Convert the arrowscrollbox binding to a Custom Element r=dao

scrollbox of an arrowscrollbox of a menupopup has @orient=vertical which should keep its content vertically aligned (a child html:slot has display:contents so it has no effect), however inspector's computed style claims the scrollbox has -moz-box-orient: horizontal, which is missed from css rules, so I assume it goes somewhere from native XUL layout implementation (also having these lines [1] support this thesis). When I change -moz-box-orient style to vertical, then the menupoup looks normal.

My guess would be is @orient is ignored by layout for some reason, while @orient attribute is propagated from arrowscrollbox [2] to scrollbox [3].

I suppose the easiest fix will be is to make [1] unconditional (confirmed it fixes the issue, however supposedly bug 1590280 makes layout jumpy). Having said that this is something @emilio might want to look at. The weirdest thing here is opening Browser Toolbox is mystically related with the behavior: I cannot reproduce the bug having no BrowserToolbox open, and it's about 100% reproducible if it's open.

[1] https://searchfox.org/mozilla-central/source/toolkit/content/xul.css#585
[2] https://searchfox.org/mozilla-central/source/toolkit/content/widgets/menupopup.js#88
[3] https://searchfox.org/mozilla-central/source/toolkit/content/widgets/arrowscrollbox.js#18

I swear we bumped into this before: https://bugzilla.mozilla.org/show_bug.cgi?id=1514926#c16, but we worked around it by setting the attr in connectedCallback instead of the constructor. I know for panel we did something as a perf optimization to avoid attribute inheritance https://searchfox.org/mozilla-central/rev/55aa17110091deef24b913d033ccaf58f9c6d337/toolkit/content/widgets/panel.js#88 which might be a better workaround for this problem if there's not a viable platform fix.

(In reply to Brian Grinstead [:bgrins] from comment #10)

I swear we bumped into this before: https://bugzilla.mozilla.org/show_bug.cgi?id=1514926#c16, but we worked around it by setting the attr in > connectedCallback instead of the constructor.

which attr? I didn't catch the idea. Bug 1514926 comment 19 suggests the fix was for arrowscrollbox (the binding we deal here) is to remove delayed connected callback.

I know for panel we did something as a perf optimization to avoid attribute inheritance https://searchfox.org/mozilla-central/rev/55aa17110091deef24b913d033ccaf58f9c6d337/toolkit/content/widgets/panel.js#88 which might be a better workaround for this problem if there's not a viable platform fix.

must be less destructive than to put those styles into xul.css, if nobody is against it, then I can file a patch for this workaround.

Yes, this is silly, we should figure out what's going on... If you're gonna go with the workaround, which looks like it, please file a bug with STR (which I guess will just be "revert patch, use str from one of the comments in the bug"), and I'll get to it.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #13)

Yes, this is silly, we should figure out what's going on... If you're gonna go with the workaround, which looks like it, please file a bug with STR (which I guess will just be "revert patch, use str from one of the comments in the bug"), and I'll get to it.

done, filed bug 1590513

Itiel, did you happen to have the browser toolbox or similar open when it happened? Something else like that maybe?

I'm curious because now I understand what's going on when the browser toolbox is open, but I can't think of many other situations that would trigger this condition... this. Some add-ons may, I guess...

(In reply to Emilio Cobos Álvarez (:emilio) from comment #15)

Itiel, did you happen to have the browser toolbox or similar open when it happened? Something else like that maybe?

Yes, the toolbox is opened here most of the time lately.

That's a bit of a relief. Then this is bug 1590280, just hitting a XUL layout bug on top. Let's track a solution there.

The menu displayed horizontally problem seems to be fixed by Bug 1592369.

Fixed range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cf30ec111af997c5af52ee427befdfe67b33e59e&tochange=c58aa1b00988718389d5448a9cddf2ff1f7a3d8b

Going to mark this as fixed and not a dupe, since this is fixed independently of Bug 1590280.

Conrfimed issue with 72.0a1 (2019-10-21) on Windows 10.
Fix verified with 73.0b11 on Windows 10, macOS 10.15, Ubuntu 19.04.