1589089 - Menulists (esp. bookmarks) are displayed horizonally

Status: VERIFIED FIXED

(Toolkit :: UI Widgets, defect)

Description

[Itiel]

Attachment: Screenshot

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.

Comment 1

[Itiel]

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

Comment 2

[Marco Bonardo [:mak]]

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

Comment 3

[Brian Grinstead [:bgrins]]

Alex said he'd take a look.

Comment 4

[alexander :surkov (:asurkov)]

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?

Comment 5

[Itiel]

(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.

Comment 6

[alexander :surkov (:asurkov)]

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.

Comment 7

[Alice0775 White]

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...

Comment 8

[Alice0775 White]

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

Comment 9

[alexander :surkov (:asurkov)]

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

Comment 10

[Brian Grinstead [:bgrins]]

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.

Comment 11

[alexander :surkov (:asurkov)]

(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.

Comment 12

[alexander :surkov (:asurkov)]

Attachment: Bug 1589089 - Set -moz-box-orient with CSS based on the arrowscrollbox orient, since the [orient] attribute on the shadow scrollbox isn't always working

Comment 13

[Emilio Cobos Álvarez (:emilio)]

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.

Comment 14

[alexander :surkov (:asurkov)]

(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

Comment 15

[Emilio Cobos Álvarez (:emilio)]

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...

Comment 16

[Itiel]

(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.

Comment 17

[Emilio Cobos Álvarez (:emilio)]

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.

Comment 18

[Alice0775 White]

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

Comment 19

[Brian Grinstead [:bgrins]]

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

Comment 22

[Cristian Fogel [:cfogel]]

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.