The "web.whatsapp.com" page doesn't open in a Facebook Container if the website was visited before installing Facebook Container

[Softvision-CristinaBadescu]

[Affected versions]:

• Firefox 59.0.2 and above

[Affected Platforms]:

• All Windows
• All Mac
• All Linux

[Prerequisites]:

• A new profile was created and the "https://web.whatsapp.com/" page was never visited.
• Have the "xpinstall.signatures.required" pref set to "false".

[Steps to reproduce]:

1. Open the Firefox browser and navigate to https://web.whatsapp.com/.
2. Navigate to "about:addons" -> Extensions tab and install the Facebook Container v1.3.0.
3. Open a new tab.
4. Navigate to https://web.whatsapp.com/ and observe the behavior.

[Expected result]:

• The page is opened in Facebook container.

[Actual result]:

• The page is opened in normal tab.

[Notes]:

• This issue is also reproducible after you restart the browser.
• If you try to open the page in a default container, it will be opened in a Facebook container. However, if you open a new tab and navigate to https://web.whatsapp.com/, the page will again be loaded in a non-container tab.
• Here is a screen recording of the issue:

[stoically]

If you try to open the page in a default container, it will be opened in a Facebook container.

Are you referring to one of the Permanent Containers (Personal, etc) here that are added by default?

Can you reproduce this with new profiles on your machine reliably? If so, could you check if after installing the Add-on the Facebook Container is correctly created? You can do so by navigating to about:preferences#containers. Thanks!

[Softvision-CristinaBadescu]

Are you referring to one of the Permanent Containers (Personal, etc) here that are added by default?

Yes, I am referring to the Permanent/Default Containers.

I can reliably reproduce this with new profiles and it seems that the Facebook Container add-on has been correctly created (I've checked the about:preferences#containers).

Below you can see a screen recording, hope it helps:

[stoically]

Just wanted to make sure. From a technical standpoint "No Container" is the "Default Container" since it is called firefox-default there. Thanks for clearing it up!

Now this is really odd behavior and I can't currently see how this is possible at all. Could you open the debug console to see if anything is logged there when navigating to WhatsApp in No Container? To do so:

• Navigate to about:debugging
• Tick the Enabled Debugging checkbox
• Scroll down to Facebook Container
• Click the debug-link and confirm the dialog
• Reproduce the issue
• Check the Console and copy & paste the error (that hopefully shows up)

Thanks!

[stoically]

Nevermind, I'm now able to reproduce.

[stoically]

This is a platform bug. The webRequest.onBeforeRequest listener never sees the main_frame request to web.whatsapp.com. Reproducible with Multi-Account Containers too by assigning web.whatsapp.com - will never show the confirm page. (Now, that's an interesting one)

[stoically]

Opened PR #106 as possible workaround. Similar to the workaround implemented for #61, as in it "only" acts retroactively. Should be reported on Bugzilla too I guess (didn't test with Nightly yet, might be worth checking).

[stoically]

Related: https://github.com/mozilla/multi-account-containers/issues/822

[stoically]

Underlying Issue here seems to be that if service workers are registered for a domain, then the request wont be fired as onBeforeRequest event.

First visit with empty cache:

Second+ visit with registered service workers:

[pdehaan]

@TanviHacks to follow up on this.

[jonathanKingston]

This is a failing in the APIs that we have for extensions (we should totally follow up on this as this impacted Lightbeam). Indeed this is due to a ServiceWorker, the request comes in as "script" not "main_frame". I'm going to work on a PR to clear them out when the extension is installed which seems the cleanest option here. We should probably clear out other storages too (perhaps in a follow up so it can be tested more).

[stoically]

I'm going to work on a PR to clear them out when the extension is installed

I believe that would only catch cases where web.whatsapp.com is visited right after installation. All visits after that would have the service worker cached and thus the same issue would occur.

[jonathanKingston]

I believe that would only catch cases where web.whatsapp.com is visited right after installation. All visits after that would have the service worker cached and thus the same issue would occur.

Right but for this addon, we then will load the worker into that tab making a default/different/none container a non issue. (I wrote this code as if we are merging your #114 PR) So the worker will exist in the FB tab and then should be ok. The same solution would have to do it on assignment for MAC.

[stoically]

Right but for this addon, we then will load the worker into that tab making a default/different/none container a non issue.

Ah true, that is indeed the cleaner solution.

[TanviHacks]

Closed #98 as a duplicate of this.

[YoAm]

FF 59.0.2 clean installation with containers extension, and facebook container 1.3.1. web.whatsapp.com has never been opened, but still fails to open in Facebook container.

[TanviHacks]

Whatsapp isn’t in 1.3.1. It should be in 1.4.0, but that release isn’t ready yet.

[Softvision-CristinaBadescu]

The latest version of Facebook Container 1.4.0 has improved the behavior, because if you already had a opened tab with the "web.whatsapp.com" page, it will be automatically contained in the Facebook container.

However, if you open a new tab the "web.whatsapp.com" page will not be opened in a Facebook container tab. This issue is reproducible using Facebook Container 1.4.0, on latest Firefox release 59.0.2, latest Nightly build 61.0a1 (2018-04-13), on Windows 10 x64, Mac 10.13.4 and Arch Linux 4.12.

Considering this, we should reopen the issue.

[jonathanKingston]

I think this might have been using an earlier 1.4.0 without the domain in there. I can't repro this. Latest build with this fix: https://github.com/mozilla/contain-facebook/pull/130#issuecomment-381122627

[Softvision-CristinaBadescu]

I've downloaded the mentioned build, Facebook Container 1.4.0, and still managed to reproduce this issue on latest Firefox Release 59.0.2, latest Nightly build 61.0a1 (2018-04-16), on Windows 10 x64, Mac 10.12.6 and Arch Linux 4.12.

[TanviHacks]

@pdehaan can you test this? It sounds like softvision and Jonathan are finding different results.

[TanviHacks]

@bakulf can you test this?

[Softvision-CristinaBadescu]

I've retested this issue and it seems that is no longer reproducible using the Facebook Container v1.4.0, on the latest Nightly build 62.0a1 (Build ID: 20180522220730), but it's still reproducible on Firefox 60.0.1 unbranded build (Build ID: 20180516032328). Tested on Windows 10 x64, Mac 10.13.3 and Arch Linux 4.12.

Considering this, I've ran the Mozregression tool, in order to find the fix. Here are the results: First good revision: 0a880af671625c7a212d30e3158a6c2a9270ce4a Last bad revision: a12624f2ce5b9d32c0a68ed8ed1ac54f99cffdd2 Pushlog: https://goo.gl/VtNAZo

From the pushlog, it seems that bug #1252998 has fixed this.

However, if we release this version to public, everyone on Fx60 will still be affected by this issue until we release Fx 61 which is the current Firefox Beta.

[DanielAlcon]

The issue is still present on FF 63.0.3 for Mac 10.14.1 and Facebook Container v1.4.2

[SoftVision-PaulOiegas]

@DanielAlcon Yes it is, because Whatsapp was not introduced anymore due to several major issues. So this remains for a future version.

[DanielAlcon]

@DanielAlcon Yes it is, because Whatsapp was not introduced anymore due to several major issues. So this remains for a future version.

Thanks, I didn't know that

[devurandom]

Has there been any effort to contain WhatsApp again? I am on Facebook Container 2.1.2 and followed the work-around described in https://github.com/mozilla/multi-account-containers/issues/822#issuecomment-452068677, but still no luck -- WhatsApp insists on opening in the default container.