Facebook links opened from 3rd party apps while the browser is closed will not be loaded in a Facebook container tab about contain-facebook HOT 16 CLOSED

KNown limitation - we are working on a solution: https://bugzilla.mozilla.org/show_bug.cgi?id=1447551

from contain-facebook.

What happens if you then try to login to facebook.com in the normal tab?

Also, instead try this with Multi-Account Containers.

1. Install MAC in a fresh profile
2. Create a Facebook Container
3. Open Facebook Container
4. Go to facebook.com in the Facebook Container tab and select to assign the container
5. Visit facebook.com in a regular Container
6. Answer the prompt to always remember to open facebook.com only in the Facebook Container and proceed to facebook in the facebook container.
7. Close the browser
8. Click a link form an external app to facebook.com

What is the result?

And try it this way too:

1. Install MAC in a fresh profile
2. Create a Facebook Container
3. Open Facebook Container
4. Go to facebook.com in the Facebook Container tab and select to assign the container
5. Close the browser
6. Click a link form an external app to facebook.com

I wonder why we aren't intercepting the request. A browser startup issue?

Adding @pdehaan

from contain-facebook.

I just tested the first STR above, same issue. And while I was testing I think it occurred to me why this doesn't work. We are doing the interception and redirection with web extensions. When you launch the browser, we open the window as soon as possible. My guess is that the web extensions haven't finished loading yet, and we have already opened the page, so the extension misses the chance to intercept the request. This might be a limitation of the extension APIs - in Firefox OS we had to create a special API for specifically this type of race and I don't believe there is such a mechanism in extensions. Chrome has a "background" permission[1] which loads the browser in a hidden state to support this sort of use case. To my knowledge Firefox doesn't support this though.

[1] https://developer.chrome.com/extensions/declare_permissions

from contain-facebook.

@TanviHacks, if I try to log in in the normal tab, it is closed and the Facebook container is opened asking me to log in for a second time. The same thing happens if I click on any link from the page.
I've also tried the 2nd STR you mentioned and the same thing as the initial report happens. The website is opened in in a normal tab instead of the assigned Facebook container.

I understand that this is a limitation, but we need to somehow mask this like a silent fail or somehow refresh the page when this happens, at least until bug 1447551 is fixed. Otherwise people we'll keep reporting that after browser start-up, the add-on no longer works.

from contain-facebook.

I've added a possible fix in #78

from contain-facebook.

To elaborate on how the fix in #78 works: The Add-on checks on initialization all open tabs for FACEBOOK_DOMAINS and if a tab is detected, it gets reopened. Since initialization also happens after browser start, tabs that might got opened before the Add-on fully initialized will also reopen in the Facebook Container.

from contain-facebook.

@stoically Does that mean that facebook.com is first opened in the default container?

That may sound harmless since you aren't logged in, but consider this - you use Thunderbird for email. You are emailed a facebook link from facebook. You click on the link - the link has identifying information that ties you to your identity/email address. The broser loads facebook.com in the default container. With the load, Facebook thinks they know who you are (even though you have not logged in) and cookies you accordingly. The browser navigates you to facebook in the Facebook Container. But its too late - we've polluted the default Container.

from contain-facebook.

@TanviHacks That's correct, the workaround would work that way. However, if we implement #74 (comment) that would no longer be a problem since the cookie are allowed to enter storage, but will never be added to Headers if not in the Facebook Container.

from contain-facebook.

Okay, then lets go with this for now, and then work on #74 (comment) as a followup (since that is more complex).

Should this be in 1.3.0, which we hope to release this week? Labeling it for now.

from contain-facebook.

Actually, the PR is quite large. I'm not sure we want to take that on in 1.3.0, or wait until another release.

from contain-facebook.

Most of it are structural refactorings to avoid code duplication since this change needs to do the "should this Tab reopened into the Facebook Container or reopened in the Default Container" in two places now: when a request comes in and when initializing for every tab, which makes it look like a large PR. The core logic is still the same.

Essentially moved this into this to be able to call it from both places.

from contain-facebook.

Would have been nice to have this included too. I think it would chop of some current bad reviews where end users reported FC not working at browser start.

from contain-facebook.

I couldn't reproduce this on the latest 1.3.0. I created a profile, installed the 1.3.0 extension, quit the browser.

In IRCCloud app, I clicked a link to "facebook.com", and Firefox Nightly opens with the profile and facebook.com opens in the container tabs.

I even bloated up the profile with a bunch of tabs open to Buzzfeed articles, with browser.sessionstore.restore_on_demand set to false so all the tabs would start loading with Firefox startup ... and I still couldn't reproduce. 😢

Is there any chance this could have been fixed by something already in 1.3.0 ?

from contain-facebook.

@groovecoder Did you test with the links provided from @SoftVision-CiprianMuresan here #78 (comment)? Sometimes initial page-size seems to be relevant and facebook.com itself is somewhat optimized.

I can't think of any code since 1.2.4 that might've fixed the issue. @SoftVision-CiprianMuresan Maybe you could test again with 1.3.0 and see if its still reproducible for you (without #78)?

from contain-facebook.

I was unable to reproduce the issue w/ 1.3.1 using some random Facebook page URLs as well as Ciprian URLs from the #78 (comment).

from contain-facebook.

Fixed via #78

from contain-facebook.