Tested with:

Nightly 88.0a1 (2021-03-02)

Tested on:

Windows 10
MacOS 10.15

Preconditions:

In latest Nightly, set browser.proton.enabled = true

Steps:

1. Launch firefox and resize the browser until the "more tools" arrows are displayed (right next to the address bar).
2. Click the arrows in order to expend the submenu and click on "Firefox Account" option.

Actual result:

There is an arrow displayed to the right of the "Firefox Account" (which suggest there is a submenu) like for the options that expends a submenu, even if there doesn't exist a FxA submenu.

Expected result:

The arrow should not be displayed since there is not a submenu opened. By clicking on the Firefox Account, the user is redirected to the Firefox Sync page.

Notes:
The issue is reproducible only with Proton enabled. In Release 86, Beta 87 or latest Nightly without Proton enabled there is a submenu that is opened.

Can you reproduce this on a clean profile? Were you in the middle of setting up a Firefox Account?

Can you reproduce this if you right click on the Firefox Accounts button and choose "Pin to overflow" (with the window not made smaller)?

I can't reproduce this on m-c tip as of yesterday (3/3/2021) with a temp profile.

Hi,
Yes, I can reproduce it with a clean profile, only change that I made is to set the Proton pref to true and restart the browser. I didn't start setting up a Firefox Account, just open the browser, change the proton pref to true and reproduce the issue. Also there is the same behavior by Pinning to overflow the Firefox Accounts button without resizing the window. The right arrow which usually suggest that by clicking on that option, a submenu will be opened.

Can you retest now that bug 1686521 has landed? I would have expected that bug to have addressed this in the sense that the button should be hidden.

Oh, never mind, looks like the button doesn't get hidden except if it's directly in the navbar.

Feels like that selector should be changed so the item is also hidden in the overflow menu (both if pinned and unpinned, which will be different parent elements. Sam, can you take a look?

(In reply to :Gijs (he/him) from comment #4)

Oh, never mind, looks like the button doesn't get hidden except if it's directly in the navbar.

Feels like that selector should be changed so the item is also hidden in the overflow menu (both if pinned and unpinned, which will be different parent elements. Sam, can you take a look?

I'll take a look at this. The intention was to not hide it in the overflow menu if the user put it there. The reasoning being that the impetus behind removing it from the navbar was to reduce clutter, and the overflow menu accomplishes the same goal. Also hiding it in there when the user went out of their way to move it there seems a bit unexpected to me. If there's a way to distinguish the button being there because the toolbar overflowed vs. the user choosing to put it there, I could adjust the selector for that?

Regardless, the submenu arrow shouldn't be there if there is no submenu - that is certainly a bug.

(In reply to Sam Foster [:sfoster] (he/him) from comment #5)

If there's a way to distinguish the button being there because the toolbar overflowed vs. the user choosing to put it there, I could adjust the selector for that?

Yes, there's the #widget-overflow-list container for the toolbar overflow and #widget-overflow-fixed-list for the items that are "pinned" to the overflow menu.

Regardless, the submenu arrow shouldn't be there if there is no submenu - that is certainly a bug.

Agreed.

The comments here should make this fixable.