Closed Bug 1317138 Opened 3 years ago Closed 3 months ago

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

Categories

(Firefox :: Tabbed Browser, defect, P2)

52 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 70
Tracking Status
firefox52 --- wontfix
firefox57 --- wontfix
firefox70 --- fixed

People

(Reporter: sebo, Assigned: dennisschagt, Mentored)

References

(Blocks 1 open bug)

Details

(Keywords: good-first-bug, Whiteboard: [userContextId])

Attachments

(4 files, 4 obsolete files)

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
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 :).
Mentor: jkt
Keywords: good-first-bug
(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.
(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.
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.
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 :)
Flags: needinfo?(sammyahad786)
Flags: needinfo?(anandbala1597)
Priority: -- → P2
Whiteboard: [userContextId]
We should ask UX if we are allowed to add this tooltip in Nightly only.
Priority: P2 → P3
Flags: needinfo?(jkt)
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.
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.
Flags: needinfo?(jgruen)
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.
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.
Clearing needinfo until jgruen has approved.

We could consider adding this to the test pilot instead?
Flags: needinfo?(jkt)
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.
Attachment #8825195 - Flags: review+
Attachment #8825195 - Flags: feedback+
Attachment #8825195 - Flags: checkin+
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?
Attachment #8825195 - Flags: review-
Attachment #8825195 - Flags: review+
Attachment #8825195 - Flags: feedback+
Attachment #8825195 - Flags: checkin+
(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?
Attached patch patch file v1 (obsolete) — Splinter Review
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.
Attachment #8825195 - Attachment is obsolete: true
Attachment #8825351 - Flags: review?(jkt)
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
Attachment #8825351 - Flags: review?(jkt) → review-
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
Assignee: nobody → aditya.bharti
Flags: needinfo?(sammyahad786)
Flags: needinfo?(jgruen)
Flags: needinfo?(anandbala1597)
Flags: needinfo?(aditya.bharti)
(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?
Flags: needinfo?(aditya.bharti) → needinfo?(jkt)
Attached patch patch file v2 (obsolete) — Splinter Review
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.
Flags: needinfo?(jkt)
Attachment #8825416 - Flags: review?(jkt)
Attachment #8825351 - Attachment is obsolete: true
> 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?
Attached patch 1317138v3.diff (obsolete) — Splinter Review
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.
Attachment #8825416 - Attachment is obsolete: true
Attachment #8825416 - Flags: review?(jkt)
Attachment #8825732 - Flags: review?(jkt)
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.
Flags: needinfo?(jkt)
Flags: needinfo?(aditya.bharti)
Attached patch pathc file v4Splinter Review
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.
Attachment #8825732 - Attachment is obsolete: true
Attachment #8825732 - Flags: review?(jkt)
Flags: needinfo?(aditya.bharti)
Attachment #8825989 - Flags: review?(jkt)
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!
Hey any update on this?

Do you need further help?
Thanks
Flags: needinfo?(jkt) → needinfo?(aditya.bharti)
Priority: P3 → P2
(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.
Flags: needinfo?(aditya.bharti)
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.
Flags: needinfo?(jkt)
Mass wontfix for bugs affecting firefox 52.
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
Flags: needinfo?(jkt) → needinfo?(aditya.bharti)
Attachment #8825989 - Flags: review?(jkt) → review-
Aditya, are you still interested in finishing your patch?

Sebastian
Hi,
Kindly review it and let me know if any changes are required.
Thanks
As Aditya didn't react to my request, I've assigned the bug to you now, Aastha.

Sebastian
Assignee: aditya.bharti → aastha.gupta4104
Status: NEW → ASSIGNED
Flags: needinfo?(aditya.bharti)
Comment on attachment 8905600 [details] [diff] [review]
improving translation text when containers is enabled

Jonathan, could you do the review here, please?

Sebastian
Attachment #8905600 - Flags: review?(jkt)
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 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!
Attachment #8905600 - Flags: review?(jkt) → review-
Aastha, are you still planning to finish this patch?

Sebastian
Flags: needinfo?(aastha.gupta4104)
yes
Flags: needinfo?(aastha.gupta4104)

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

Thanks

Flags: needinfo?(sebastianzartner)
Flags: needinfo?(jkt)

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.

Flags: needinfo?(jkt) → needinfo?(shivams2799)
Flags: needinfo?(sebastianzartner)

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.

Flags: needinfo?(jkt)

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

Flags: needinfo?(bmikel)

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

Flags: needinfo?(bmikel)
Attachment #9077178 - Attachment description: Summary: Add extra info in new-tab tooltip when containers are enabled → Summary: Add extra info in new-tab tooltip when containers are enabled

@Betsy: Thanks, good idea, done.

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

Flags: needinfo?(jkt)

(fixed assignee status and clearing obsolete ni)

Assignee: aastha.gupta4104 → dennisschagt
Flags: needinfo?(shivams2799)

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

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

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

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 -

Flags: needinfo?(dennisschagt)

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

Flags: needinfo?(dennisschagt)
Keywords: checkin-needed

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

Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70

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

Status: RESOLVED → VERIFIED
Depends on: 1575238
You need to log in before you can comment on or make changes to this bug.