1317138 - Add info to tooltip of "plus button" that long press opens containers menu

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P2)

Description

[Sebastian Zartner [:sebo]]

Hovering the "plus button" within the tab bar provides a tooltip telling that it opens a new tab.

Now that bug 1272256 is fixed it should also say that a long press opens the container tab menu.

Sebastian

Comment 1

[Jonathan Kingston [:jkt] he/him]

Happy to fix this if we don't get takers but willing to be a mentor if someone wants to take a look at this :).

Comment 2

[Anand Balakrishnan [:anand-bala]]

(In reply to Jonathan Kingston [:jkt] from comment #1)
> Happy to fix this if we don't get takers but willing to be a mentor if
> someone wants to take a look at this :).

Hello, I was wondering if you could help me with how to go about fixing this bug.

Comment 3

[Anand Balakrishnan [:anand-bala]]

(In reply to Anand Balakrishnan [:anand-bala] from comment #2)
> (In reply to Jonathan Kingston [:jkt] from comment #1)
> > Happy to fix this if we don't get takers but willing to be a mentor if
> > someone wants to take a look at this :).
> 
> Hello, I was wondering if you could help me with how to go about fixing this
> bug.

Thank you.

Comment 4

[Sammy Ahad]

This is my first bug, can I get some extra information about where to fix this bug? Is it part of the Firefox browser's html components? etc. 
Thanks.

Comment 5

[Jonathan Kingston [:jkt] he/him]

First off you will need to build a copy of Firefox from Mozilla central code, sometimes referred to as MC on Bugzilla: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build

Make sure you get all the build prerequisites before continuing to download and build the source code, both downloading and building are likely to take over 20 minutes each and depending on your computer and internet connection could be over an hour for each.

Once you have a running version as central, you can then start debugging the interface of Firefox, the quickest way to do this is using the browser toolbox, follow the steps in this MDN article to enable this: https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox
The browser toolbox should allow you to inspect the button to discover it's id, class and other attributes. (Fun fact: there is actually two new tab buttons, one when you have a few tabs and another when you have lots when you also see a little down arrow to expand more tabs)

Now you know a little about the button you can start searching the source. The quickest way to browse the source is usually searching using one of the two tools http://searchfox.org and https://dxr.mozilla.org/mozilla-central/source/ (!mozsf and !mozdxr if you use Duck Duck Go as your search engine) so you can then search the code for the ids you just found such as https://dxr.mozilla.org/mozilla-central/search?q=new-tab-button&redirect=false you will likely find most interface in either xul or xml files. xul is an xml based interface language that is used within Firefox and also xml files are often used for bindings in CSS which is for attaching components and behaviour to an element (if you are familiar with web components then a lot of the concepts are at play here).

Another quick way of finding translation text is to search for the USA English version of the text as by default all of the interface is built in American English then translated to all other languages, only this version of the translation text is present in Mozilla Central.

You will often find translation text inserted in elements like &thistext.label; this will correlate to a entry in a translations.dtd file searching for "thistext.label" will find the dtd file usually. Another type of translations is also used within dynamic files too https://dxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/aboutPrivateBrowsing.properties property files are excactly the same concept but used for lookups within JavaScript. We also will dynamically copy an elements translations when multiple elements on a screen share the translation to reduce the number of lookups.

Once you have made your change you can then run ./mach build and ./mach run again to see your changes within the browser.

One of the simplest ways to get your patch onto Bugzilla is running:
  hg commit -m "Bug 1317138 - improving translation text when containers is enabled"
  hg export > bug-1317138.patch
Then attaching the output file to the bug.

Please note this new translation can't be present when containers is disabled as at the moment containers will be disabled in stable and developer mode firefox by default. This means there will need to be a scripted change based upon the "privacy.userContext.enabled" preference - searching for this will find the code that disables the button changes within the browser.

Please 'Need info' me if you have any questions, you can do this on Bugzilla when you make a comment and tick the need more information checkbox. Type ":jkt" and you should find me :)

Comment 6

[Tanvi Vyas[:tanvi]]

We should ask UX if we are allowed to add this tooltip in Nightly only.

Comment 7

[Thomas Charles]

Attachment: Screenshot of Updated Tooltip for Bug-1317138.png

Comment 8

[Thomas Charles]

Hi

This is only my second bug and I'm looking at working on it, if it is still available. I have attached a screenshot of the progress I have made so far.

I was just hoping for some clarification if possible on making this enabled only for Nightly.

Thanks.

Comment 9

[Tanvi Vyas[:tanvi]]

Thomas - The change should only happen if the about:config setting privacy.userContext.enabled is set to true.  Otherwise, this tooltip shouldn't exist.

Needinfo'ing John Gruen to make sure we are okay to have this tooltip if Containers is enabled on a browser (i.e. Nightly only).  Draft: https://bugzilla.mozilla.org/attachment.cgi?id=8816428

We also need to refine the text - "Hold to open a container tab menu".  Maybe "Hold to pick a Container tab".  I'm also not sure if "hold" is the right word.  For the back button, the tooltip says "Pull down to show history".  Either pulling down or holding works to show the history.

Comment 10

[Aditya Bharti [:adbugger]]

Hi,
This is my first bug and I want to work on it. So far, I've made progress trying to understand the codebase. I've found the browser.properties file which sets the tooltip string for the new tab button.

Could you tell me how to set this dynamically, because as of now it seems to hard coded in the file?

Thanks.

Comment 11

[Aditya Bharti [:adbugger]]

Hi,
This is my first bug and I want to work on it. So far, I've made progress trying to understand the codebase. I've found the browser.properties file which sets the tooltip string for the new tab button.

Could you tell me how to set this dynamically, because as of now it seems to hard coded in the file?

Thanks.

P.S. Needinfo'ing on this comment.

Comment 12

[Jonathan Kingston [:jkt] he/him]

Clearing needinfo until jgruen has approved.

We could consider adding this to the test pilot instead?

Comment 13

[Aditya Bharti [:adbugger]]

Attachment: Updated tooltip for bug 1317138 browser.js

Changed the tooltip based on whether containers are enabled or inPrivate browsing is active. Will use observers for pref changes in next iteration of patch. Currently tooltip change requires restart.

I'm new to this process, so I'll looking for an easy way to understand how to submit patches and getting bugs assigned.

Comment 14

[Jonathan Kingston [:jkt] he/him]

Comment on attachment 8825195 [details] [diff] [review]
Updated tooltip for bug 1317138 browser.js

Unfortunately we can't accept uploads of files like this (files change so often we would end up losing work), are you able to create a mercurial style .patch file by exporting the code out?

Comment 15

[Aditya Bharti [:adbugger]]

(In reply to Jonathan Kingston [:jkt] from comment #14)
> Comment on attachment 8825195 [details] [diff] [review]
> Updated tooltip for bug 1317138 browser.js
> 
> Unfortunately we can't accept uploads of files like this (files change so
> often we would end up losing work), are you able to create a mercurial style
> .patch file by exporting the code out?

Not yet. I'm working on the Mercurial aspect too right now. Sorry, I'm new to this.
Just a clarification, does the tooltip change actually need to be live, i.e, not require a restart?

Comment 16

[Aditya Bharti [:adbugger]]

Attachment: patch file v1

Uploaded a mercurial style .diff file by exporting the code.
Changed browser.js and browser.properties
Currently tooltip change requires a restart. Will create observers for pref changes in v2.

P.S. Apologies for the confusion before.

Comment 17

[Jonathan Kingston [:jkt] he/him]

Comment on attachment 8825351 [details] [diff] [review]
patch file v1

Patch should not change code in: security/manager/ssl/StaticHPKPins.h

As mentioned the code should observe the changes of: privacy.userContext.enabled

Nit: browser/base/content/tabbrowser.xml has added whitespace after the code:
               const newTab2 = document.getAnonymousElementByAttribute(this, "anonid", "tabs-newtab-button")

Localisation note should come after the heading:
+# LOCALIZATION NOTE (newTabContainer.tooltip):
+# New Tab button tooltip with containers enabled

Comment 18

[Jonathan Kingston [:jkt] he/him]

As discussed rather than doing an observer potentially a solution that checks an array not specific to containers of
    array[pref] = [key: string, key2: string]

    or

    array[key] = [pref: string];

in UpdateDynamicShortcutTooltipText (http://searchfox.org/mozilla-central/source/browser/base/content/browser.js#5376) might work.

As mentioned by dao "it's a general-purpose function, no container specifics should be baked into it" but the array could be external like nodeToShortcutMap is.

I am assigning the work to you as you are actively working on it with a patch. I also don't think this impacts jgruen's decision as test pilot can do a different thing etc.

Also I think the text should match the back button, the functionality of pulling down does the same so the string should probably be (currently no right click):

  newTabContainer.tooltip=Open a new tab (%S)\nPull down to open container menu

Comment 19

[Aditya Bharti [:adbugger]]

(In reply to Jonathan Kingston [:jkt] from comment #18)
> As discussed rather than doing an observer potentially a solution that
> checks an array not specific to containers of
>     array[pref] = [key: string, key2: string]
> 
>     or
> 
>     array[key] = [pref: string];
> 
> in UpdateDynamicShortcutTooltipText
> (http://searchfox.org/mozilla-central/source/browser/base/content/browser.
> js#5376) might work.
> 
> As mentioned by dao "it's a general-purpose function, no container specifics
> should be baked into it" but the array could be external like
> nodeToShortcutMap is.
> 
> I am assigning the work to you as you are actively working on it with a
> patch. I also don't think this impacts jgruen's decision as test pilot can
> do a different thing etc.
> 
> Also I think the text should match the back button, the functionality of
> pulling down does the same so the string should probably be (currently no
> right click):
> 
>   newTabContainer.tooltip=Open a new tab (%S)\nPull down to open container
> menu

Changed the string.

I'm not sure what you mean by "check an array of prefs". Does the array contain a list of all prefs? Also, a question about the function you've mentioned:
The first solution I had tried was to update the UpdateDynamicShortcutTooltipText function to explicitly check if the nodeId == "new-tab-button" and then set the tooltip according to the preferences.

That solution didn't work because once the nodeId is added to gDynamicTooltipCache and the strId is set, then subsequent calls to to UpdateDynamicShortcutTooltipText will not modify gDynamicTooltipCache[nodeId] without a browser restart.

What I was thinking of is to modify a function which is executed every time a pref changes. Any ideas on how to move forward?

Comment 20

[Aditya Bharti [:adbugger]]

Attachment: patch file v2

Uploading v2 of patch file.

Tooltip change is live. Now however, the gDynamicTooltipCache is always updated, regardless of whether the nodeId is present or not.

If the updater function is to be kept general purpose then we would have to check the value in the cache anyway,(or explicitly check which nodeId was being updated) so I don't think there's a significant impact on performance.

Awaiting feedback.

Comment 21

[Jonathan Kingston [:jkt] he/him]

> The first solution I had tried was to update the UpdateDynamicShortcutTooltipText function to explicitly check if the nodeId == "new-tab-button" and then set the tooltip according to the preferences.

The array I mentioned should effectively do the same check as this however be populated outside the function UpdateDynamicShortcutTooltipText and be usable by other developers that want a pref to control prefs being enabled to setting code. As the current nodeToTooltipMap looks like it is only checked once rather than after the pref changes.

- Remove the comment "/* Changed lines */"

> If the updater function is to be kept general purpose then we would have to check the value in the cache anyway,(or explicitly check which nodeId was being updated) so I don't think there's a significant impact on performance.

This doesn't look like what the attached patch does. If you update the preference does the browser stop showing that tooltip change?

Comment 22

[Aditya Bharti [:adbugger]]

Attachment: 1317138v3.diff

Tooltip change is finally live.

In the array approach, could not figure out how to update the array after every pref change. So, implemented a solution where the update tooltip function checks which version of two possible nodeToTooltipMaps to use (the check is actually performed by an external function, which can be modified to accommodate other prefs also).

Also, the tooltip cache is always updated.

Comment 23

[Jonathan Kingston [:jkt] he/him]

I think you are going to have to have pref observers to update the nodeToShortcutMap instead. We can't have specific code to containers in UpdateDynamicShortcutTooltipText even if it is in a separate function.

Needinfoing myself to explain better later.

Comment 24

[Aditya Bharti [:adbugger]]

Attachment: pathc file v4

Alright, based on the feedback I've finally moved all container specific code to an observer defined after the tooltip cache map.

The observer needs to delete the old nodeId from the cache every time the pref value changes, that's why the cache is defined first.

Also, when nodeToTooltpMap is initialized, it checks the value of privacy.userContext.enabled because the observer will not update the tooltip when the browser window is first initialized.

Comment 25

[Jonathan Kingston [:jkt] he/him]

Comment on attachment 8825989 [details] [diff] [review]
pathc file v4

Review of attachment 8825989 [details] [diff] [review]:
-----------------------------------------------------------------

The Preferences object isn't used elsewhere in this file so it's likely bad to start now, I would change the code to use: Services.obs.addObserver(methodName, "privacy.userContext.enabled", false);

"privacy.userContext.enabled" will likely need be be unobserved also on shutdown just to be tidier. This should work by running removeObserver in "onUnload() {" http://searchfox.org/mozilla-central/source/browser/base/content/browser.js#1474

I have not seen other code that does multi statement ternary statements in Firefox, I would prefer the code to look like this:

if (newPrefValue) {
  nodeToTooltipMap["new-tab-button"] = "newTabContainer.tooltip";
  nodeToTooltipMap["tabs-newtab-button"] = "newTabContainer.tooltip";
} else {
  nodeToTooltipMap["new-tab-button"] = "newTabButton.tooltip";
  nodeToTooltipMap["tabs-newtab-button"] = "newTabButton.tooltip";
}


When you click "raw unified" after viewing the diff on bugzilla previous revisions shouldn't be visible: https://bug1317138.bmoattachments.org/attachment.cgi?id=8825989 for example I can see your old methods updateUseAltTooltip. Mercurial provides you with the ability to squash these together by amending the commit (I'm not sure on the workflow you are using for the diffs, however we have lots of people on irc that would be better at explaining a solution for you on that)

Let me know when you have those and I can test it out, looking really good :)
Thanks!

Comment 26

[Jonathan Kingston [:jkt] he/him]

Hey any update on this?

Do you need further help?
Thanks

Comment 27

[Aditya Bharti [:adbugger]]

(In reply to Jonathan Kingston [:jkt] from comment #26)
> Hey any update on this?
> 
> Do you need further help?
> Thanks

Sorry for the long absence. Lots of things came up but now I'm finally back in front of a computer. 

Yes, so, the squashing of commits has been done, code has been changed. But I'm still having trouble regarding the Services.obs.addObserver method.

I'm trying to follow 
https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Preferences#Using_preference_observers and https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIPrefBranch#addObserver() .

But I need help with the concept of pref branches. Further, both these methods require an nsIObserver object, which I still am trying to grasp. However, the other changes have been done.

Once again, extremely sorry for the delay. Please PM me if you need any further details.

Comment 28

[Aditya Bharti [:adbugger]]

So I'm trying to use preference observers as suggested here: https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Preferences#Using_preference_observers

And, following the same pattern, I've written an observer:

var userContextObs = {
  register: function() {
    var prefService = Cc["@mozilla.org/preferences-service;1"].getService(Ci.nsIPrefService);
    this.branch = prefService.getBranch('privacy.userContext.');
    if(!("addObserver" in this.branch))
      this.branch.QueryInterface(Components.interfaces.nsIPrefBranch2);
    this.branch.addObserver("", this, false);
  },

  unregister: function() {
    this.branch.removeObserver("", this);
  },

  observe: function(aSubject, aTopic, aData) {
    console.log(aSubject+aData);
  }
};
userContextObs.register();

This doesn't seem to work, as there is no output on the console. Further, after even one pref change, the tooltip text changes to "Open a new tab ((null)) \n Pull down to open container menu", even though I haven't changed the shortcut map anywhere.

Waiting for further help.

Comment 29

[Julien Cristau [:jcristau] (back April 22)]

Mass wontfix for bugs affecting firefox 52.

Comment 30

[Jonathan Kingston [:jkt] he/him]

Hi,
I'm super sorry for the delay here, we were working on the test pilot code and releases there.

Observers won't fire the first time, so you will also have to check the preference the first run through or call the callback manually.

I'm not sure about the shortcut changing, are you able to post the code sample?

Again sorry for the big pause here, let me know if you want to pass on this I will however be more available now.

Thanks

Comment 31

[Sebastian Zartner [:sebo]]

Aditya, are you still interested in finishing your patch?

Sebastian

Comment 32

[Aastha]

Attachment: improving translation text when containers is enabled

Hi,
Kindly review it and let me know if any changes are required.
Thanks

Comment 33

[Sebastian Zartner [:sebo]]

As Aditya didn't react to my request, I've assigned the bug to you now, Aastha.

Sebastian

Comment 34

[Sebastian Zartner [:sebo]]

Comment on attachment 8905600 [details] [diff] [review]
improving translation text when containers is enabled

Jonathan, could you do the review here, please?

Sebastian

Comment 35

[Firefox Bug Husbandry Bot]

Bulk change per https://bugzilla.mozilla.org/show_bug.cgi?id=1401020

Comment 36

[Sebastian Zartner [:sebo]]

The patch for this is lying around for a very long time now. Jonathan, could you please do the review or assign it to someone else?

Sebastian

Comment 37

[Jonathan Kingston [:jkt] he/him]

Comment on attachment 8905600 [details] [diff] [review]
improving translation text when containers is enabled

Review of attachment 8905600 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the delay here!

There are some linting bugs I can see for starters:

/browser/base/content/browser.js
   554:3   error  Expected method shorthand.                                                     object-shorthand (eslint)
   555:17  error  Strings must use doublequote.                                                  quotes (eslint)
   560:7   error  Closing curly brace does not appear on the same line as the subsequent block.  brace-style (eslint)
   561:7   error  Expected space(s) after "else".                                                keyword-spacing (eslint)
  1446:5   error  addObserver's third parameter can be omitted when it's false.                  mozilla/no-useless-parameters (eslint)


Also:
> if (Services.prefs.getBoolPref("privacy.userContext.enabled")) {

This will have to check for if the user is in private browsing mode too with: "&& !PrivateBrowsingUtils.isWindowPrivate(window)) {"


Can you make the following a method on newTabTooltipHandler that both observe and this part of the code calls:
>+if (Services.prefs.getBoolPref("privacy.userContext.enabled")) {
>+  nodeToTooltipMap["new-tab-button"] = "newTabContainer.tooltip";
>+  nodeToTooltipMap["tabs-newtab-button"] = "newTabContainer.tooltip";
>+}
>+

Could you clear items out of: gDynamicTooltipCache instead of using: gDynamicPrefUpdated? Perhaps implement this in a method DeleteDynamicShortcutTooltipText that observe can call.

Thanks!

Comment 38

[Sebastian Zartner [:sebo]]

Aastha, are you still planning to finish this patch?

Sebastian

Comment 39

[Aastha]

yes

Comment 40

[Shivam Singhal [ :championshuttler ]]

Hi :sebo, :jkt, I would like to work on it, can you help me getting started?

Thanks

Comment 41

[Jonathan Kingston [:jkt] he/him]

Hey Shivam,

I would first take a look the existing patch for inspiration as for some reason it hasn't broken too much in a year.

The task is to observe the container pref privacy.userContext.enabled and modify nodeToTooltipMap to match a different tooltip name based on if containers are available.

• Once the preference observer fires then the code should swap out the existing values in nodeToTooltipMap and change to the relevant disabled/enabled tooltip.
• The observer will also clear the gDynamicTooltipCache of the two node id's that we care about. (GetDynamicShortcutTooltipText short circuits if the node is already in the cache)
• Then it will trigger UpdateDynamicShortcutTooltipText on the nodes also. (we don't need the gDynamicPrefUpdated code of the previous patch)

The two buttons this patch are impacting are the normal + new tab button but also when there are many tabs we have a different + button that is right aligned (left aligned in left to right text direction).

Searchfox is your friend to find the code, searching for strings of the previous patch will find the locations that are in Firefox that will need updating.

Comment 42

[Dennis van der Schagt [:dennisschagt]]

Attachment: Summary: Add extra info in new-tab tooltip when containers are enabled

Comment 43

[Dennis van der Schagt [:dennisschagt]]

Hi :jkt, I just submitted a patch via phabricator.
Can I add you as a reviewer?

This is my first bug, please let me know if there is anything I can improve on.

Comment 44

[Tanvi Vyas[:tanvi]]

Adding Betsy for a quick content review of the new string:
newTabContainer.tooltip=Open a new tab (%S)\nClick and hold to open a new container tab

Comment 45

[Betsy Mikel [:betsymi]]

Slight edit on the string:
newTabContainer.tooltip=Open a new tab (%S)\nPress and hold to open a new container tab

Comment 46

[Dennis van der Schagt [:dennisschagt]]

@Betsy: Thanks, good idea, done.

@Jonathan: I just added you as a reviewer so I will remove the needinfo from my previous comment.

Comment 47

[Rob Wu [:robwu]]

(fixed assignee status and clearing obsolete ni)

Comment 48

[Tanvi Vyas[:tanvi]]

Should we put this behind a pref in case Facebook Container wants to turn this off?

Comment 49

[Rob Wu [:robwu]]

@Tanvi
Why would Facebook container turn this off? This tooltip reflects UI behavior of Firefox, present regardless of whether Facebook container is installed (provided that the container tabs feature is enabled, which the patch already accounts for).

Comment 50

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1c7a1d0fda0e
Summary: Add extra info in new-tab tooltip when containers are enabled r=jkt

Comment 51

[Natalia Csoregi [:nataliaCs]]

Backed out for browser-chrome failures on /browser_duplicateIDs.js

backout: https://hg.mozilla.org/integration/autoland/rev/6a05fb5dc603b8523b2a487e983fa172e82b8b39

push: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=1c7a1d0fda0e9fbb6293ee15e0596361d98b7979&searchStr=browser-chrome&group_state=expanded&selectedJob=261336857

failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=261336857&repo=autoland&lineNumber=2144

[task 2019-08-13T13:40:54.225Z] 13:40:54 INFO - TEST-PASS | browser/base/content/test/general/browser_duplicateIDs.js | new-tab-button should be unique -
[task 2019-08-13T13:40:54.226Z] 13:40:54 INFO - Buffered messages finished
[task 2019-08-13T13:40:54.227Z] 13:40:54 INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_duplicateIDs.js | newtab-popup should be unique -
[task 2019-08-13T13:40:54.230Z] 13:40:54 INFO - Stack trace:
[task 2019-08-13T13:40:54.230Z] 13:40:54 INFO - chrome://mochikit/content/browser-test.js:test_ok:1576
[task 2019-08-13T13:40:54.231Z] 13:40:54 INFO - chrome://mochitests/content/browser/browser/base/content/test/general/browser_duplicateIDs.js:test/<:7
[task 2019-08-13T13:40:54.231Z] 13:40:54 INFO - chrome://mochitests/content/browser/browser/base/content/test/general/browser_duplicateIDs.js:test:3
[task 2019-08-13T13:40:54.231Z] 13:40:54 INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1383
[task 2019-08-13T13:40:54.232Z] 13:40:54 INFO - chrome://mochikit/content/browser-test.js:nextTest/<:1209
[task 2019-08-13T13:40:54.232Z] 13:40:54 INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<:803
[task 2019-08-13T13:40:54.233Z] 13:40:54 INFO - TEST-PASS | browser/base/content/test/general/browser_duplicateIDs.js | alltabs-button should be unique -

Comment 52

[Dennis van der Schagt [:dennisschagt]]

Test failure reproduced locally.
Fixed by making sure the new-tab popups have a unique id.

Comment 53

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b00c70075119
Summary: Add extra info in new-tab tooltip when containers are enabled r=jkt

Comment 54

[Alexandru Michis [:malexandru]]

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

Comment 55

[Sebastian Zartner [:sebo]]

Tested it in Nightly 70.0a1 (2019-08-19), toggling container tabs on and off and in private browsing mode and it looks fine for me in all cases. Thank you for the fix!

Sebastian