1417238 - "Open Link in New Container Tab" submenu active but empty when there are no containers

Status: VERIFIED FIXED

(Firefox :: Menus, defect, P3)

Description

[08xjcec48]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

- Go to about:preferences#containers and delete all containers
- Open example.org
- Right-click on the link


Actual results:

"Open Link in New Container Tab" is visible and not greyed-out, even though it has no purpose with no sub-entries.


Expected results:

When there are currently no containers, the ""Open Link in New Container Tab" entry in the link context menu should be greyed-out, or it should offer the option to create a new container, or show a link to "Manage containers" (about:preferences#containers).

Comment 1

[Kohei Yoshino [:kohei]]

Please report the issue to https://github.com/mozilla/multi-account-containers/issues Thank you!

Comment 2

[Luke Crouch [:groovecoder]]

This is a platform-level bug - not an issue with the add-on.

Comment 3

[Cristina Badescu [:cbadescu], Experiments QA]

I'm thinking at two possible components for this issue: one is Core::XP Toolkit/Widgets: Menus and the other one is Firefox:: Menus. Since Containers is an add-on, I'm thinking this may not be a Core issue, but more like a Firefox issue. I'm going to move this to Firefox:: Menus for now, please correct me if I'm wrong.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

Jonathan, is this something you would be interested in?

Comment 5

[Jonathan Kingston [:jkt] he/him]

Attachment: Bug 1417238 - Hide container context menu when there are no items to display.

Review commit: https://reviewboard.mozilla.org/r/209364/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/209364/

Comment 6

[Jonathan Kingston [:jkt] he/him]

I'm not sure if it is a good idea to measure the number of containers when a context menu opens but we shall see if there are any issues in try I guess.

I would actually prefer just to show a "No containers available" or even "Add a container" linking to the about:preferences in this case.

Comment 7

[:Gijs (he/him)]

Comment on attachment 8938889 [details]
Bug 1417238 - Hide container context menu when there are no items to display.

https://reviewboard.mozilla.org/r/209364/#review215170

::: browser/base/content/nsContextMenu.js:358
(Diff revision 1)
>      }
>  
>      var shouldShow = this.onSaveableLink || isMailtoInternal || this.onPlainTextLink;
>      var isWindowPrivate = PrivateBrowsingUtils.isWindowPrivate(window);
> -    var showContainers = Services.prefs.getBoolPref("privacy.userContext.enabled");
> +    var showContainers = Services.prefs.getBoolPref("privacy.userContext.enabled")
> +                         && ContextualIdentityService.getPublicIdentities().length;

Here and in the test, please use trailing instead of leading operators (ie move `&&` to the end of the previous line), as this is convention in our codebase and also earlier in this method. We already go over 80ch per line within only a few lines of context, so I'm not so worried about that - though we might as well make the pref a lazy getter here...

Comment 8

[Jonathan Kingston [:jkt] he/him]

I think this can be done as part of this work.

> Remove sub menu when there's only one container
> The links context menu "open in new container tab" is a droplist, but when there's only one entry it's pointless, we could save one click.

I also don't think the priority needs to be this high.

Comment 9

[:Gijs (he/him)]

Attachment: Bug 1417238 - hide 'open link in container' menu when there are no containers, r?jkt

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d14daa02fb88
hide 'open link in container' menu when there are no containers, r=jkt

Comment 11

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/d14daa02fb88

Comment 12

[Sajedul Islam]

I have reproduced this bug with Nightly 59.0a1 (2017-11-14) on Windows 10 , 64 Bit !

This bug's fix is Verified with latest Nightly 70.0a1 !

Build ID :--- 20190720095435
User Agent:--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Comment 13

[Catalin Sasca, Desktop QA [:csasca]]

Thank you Sajedul for helping with the verification of this issue!