1213598 - No need to remove context menu from toolbars in fullscreen anymore

Status: RESOLVED DUPLICATE of bug 1393749

(Firefox :: Toolbars and Customization, enhancement)

Description

[Luís Miguel [:quicksaver] (not reading bugmail)]

When entering fullscreen mode, the context menu of any visible toolbars is removed [1], except for the tabs-bar and the nav-bar which is changed to the "autohide-context" menu.

The reason as described in there is "to avoid breakage", which is so incredibly vague... O.o I finally tracked it down [2] and apparently it was to avoid entering customize mode as it had some trouble when used in fullscreen (bug 202978).

None of that seems valid anymore with the new customization system in australis. Gijs, can you confirm this?

So I propose:
- move all the menu items from #autohide-context to #toolbar-context-menu
- show and hide them appropriately through the CSS selector #main-window[sizemode="fullscreen"]
- get rid of all the context menu handling stuff in FullScreen._updateToolbars()

[1] http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-fullScreen.js#579
[2] http://hg.mozilla.org/mozilla-central/diff/9b2a99adc05e/browser/base/content/browser.js#l1.3428

Comment 1

[:Gijs (he/him)]

I wasn't around for any of this.

Dão, Stephen, can you comment?

Comment 2

[Dão Gottwald [:dao]]

Somebody will probably need to go through the context menu commands and see if they all work without issues in fullscreen mode on a range of OSes. E.g. I imagine there might be styling issues with about:customizing or problems with modal dialogs.

If all commands work flawlessly, we should certainly remove this restriction. If some commands are problematic, I'm not so sure that we should just hide those. Technically, they should be disabled, not hidden, but even then users might not understand why some commands are suddenly unavailable. The whole menus being replaced is simpler and more predictable.

Comment 3

[Luís Miguel [:quicksaver] (not reading bugmail)]

(In reply to Dão Gottwald [:dao] from comment #2)
> Somebody will probably need to go through the context menu commands and see
> if they all work without issues in fullscreen mode on a range of OSes. E.g.
> I imagine there might be styling issues with about:customizing or problems
> with modal dialogs.

As far as Windows 7 goes at least, everything is working just fine. I can access customize in fullscreen through the menu panel toggler, and all menu options (Move to Toolbar/menu, Remove from..., etc.) seem to work just fine without glitches. The only exceptions are the Menu Bar and Bookmarks Toolbar menu items, which _apparently_ do nothing because those are always hidden while in fullscreen (after exiting fullscreen, I can see those toolbars were indeed toggled properly).

The only change necessary I think would be to force disable "Hide toolbars" while in customize mode, as it's just annoying that they keep moving up and down while customizing; also applying a theme through the Themes button doesn't apply the image immediately to the top area in that case, I have to exit fullscreen for it to apply (it does work immediately if I disable Hide Toolbars).

FWIW, just from looking at the whole CustomizableUI/CustomizeMode code, I don't believe they would interfere in any other OS either. What modal dialogs are there in about:customizing? Or did you mean something else?

> If some commands are problematic, I'm not so sure that we
> should just hide those. Technically, they should be disabled, not hidden,

True, but can they even be used if they're hidden anyway? I'd add a follow-up here, re-enable the "Customize" menu entry while in customize mode. Is there a reason for why it is disabled? (for another bug of course, just asking to see if it would be worth filing it then)

> but even then users might not understand why some commands are suddenly
> unavailable. The whole menus being replaced is simpler and more predictable.

I disagree with you there. While in customize mode, both the customize context menus for the menu panel and palette areas are fully active and working. I find it weird, from a UX perspective, that the equivalent menu in the toolbars isn't.

Comment 4

[Dão Gottwald [:dao]]

(In reply to Luís Miguel [:quicksaver] from comment #3)
> FWIW, just from looking at the whole CustomizableUI/CustomizeMode code, I
> don't believe they would interfere in any other OS either. What modal
> dialogs are there in about:customizing? Or did you mean something else?

"Bookmark All Tabs", for instance.

> > If some commands are problematic, I'm not so sure that we
> > should just hide those. Technically, they should be disabled, not hidden,
> 
> True, but can they even be used if they're hidden anyway?

No? But what does this have to do with what I said?

> > but even then users might not understand why some commands are suddenly
> > unavailable. The whole menus being replaced is simpler and more predictable.
> 
> I disagree with you there.

You disagree that a subset of toolbar context menu commands being unavailable for reasons users won't know is less predictable and might confuse users?

Comment 5

[Luís Miguel [:quicksaver] (not reading bugmail)]

Attachment: WhyTheDifference

(In reply to Dão Gottwald [:dao] from comment #4)
> "Bookmark All Tabs", for instance.

I did miss that one. From a quick test I don't see any visual issues at least. BTW, that command is still available by right-clicking a tab itself, rather than the toolbars (as are the other common commands).

> > > If some commands are problematic, I'm not so sure that we
> > > should just hide those. Technically, they should be disabled, not hidden,
> > 
> > True, but can they even be used if they're hidden anyway?
> 
> No? But what does this have to do with what I said?

Tab-related commands like Bookmark All Tabs are already hidden when I right-click in the nav-bar, they only appear when right-clicking the tab-bar itself. My question was more of a curiosity in the case when, if already hidden, is it worth it disabling them as well? (Of course I agree that problematic commands should be disabled.)

> > > but even then users might not understand why some commands are suddenly
> > > unavailable. The whole menus being replaced is simpler and more predictable.
> > 
> > I disagree with you there.
> 
> You disagree that a subset of toolbar context menu commands being
> unavailable for reasons users won't know is less predictable and might
> confuse users?

I think that will always happen, I already don't understand why I can't use the "Customize..." command while within customize itself to exit it. I do understand your point, but I think what I show in my screenshot is much more confusing.

As long as customization actions work in fullscreen, their menu commands should be available. Especially while customize itself is available and working in fullscreen mode.

Personally, I'd rather see the same menu, and disable/hide whatever doesn't or shouldn't work in customize/fullscreen, than have all those options completely replaced by the two single fullscreen-related commands. If any customize-related commands have problems in fullscreen mode, then customize mode itself probably shouldn't be allowed in fullscreen at all (and this bug becomes of course mute).

Comment 6

[BugBot [:suhaib / :marco]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Comment 7

[:Gijs (he/him)]

Bug 1393749 has collected some dupes so duping there; we actually show tabstrip/toolbar button context menus as normal now, as of bug 1591040.