Test results for v1.3.0

[SoftVision-PaulOiegas]

Hi team,

We’ve spent two days testing the new build v1.3.0, and we have also performed regression testing to see if the introduced changes didn’t break something else.Here are the testing results:

New issues

#98 - "web.whatsapp.com" link doesn't open in a Facebook Container if the user was previously logged in a WhatsApp account
#99 - "Go back one page" button doesn't navigate to the previous page when accessing Web WhatsApp
#100 - The "https://web.whatsapp.com/" website can wrongly be opened in a normal tab if it is specifically assigned to the MAC's "Facebook" container
#101 - The "web.whatsapp.com" page doesn't open in a Facebook Container if the website was visited before installing Facebook Container
#102 - "cdn.fbsbx" domain is opened in a normal tab when downloading a file from Messenger
#103 - You cannot log in with "Facebook" on Instagram, if it is assigned to a different container
#104 - [Enhancement] "cdn.whatsapp.net" domain should be opened in a Facebook container tab when viewing a background image from www.whatsapp.com

Known issues

#61 - Facebook links opened from 3rd party apps while the browser is closed will not be loaded in a Facebook container tab
#73 - Facebook share tabs are wrongly opened in 1st position of the tab strip

Other observed scenarios

These weren’t logged because we are unsure if they are intended behaviors or really issues.
@stoically - maybe you can share an opinion

1. If we assign Facebook to a MAC container and we access https://www.facebook.com, we received a confirmation page with “Open in current container” and “Open in <mac_container_name>”
   But if you access https://facebook.com in a new tab (without “www”), you get “Open in Facebook Container” and “Open in <mac_container_name>”.
   Same thing occurs on instagram too.
2. If we remove Facebook Container with container tabs opened, the containers are closing without any warning or confirmation requested. Also, the closed tabs cannot be brought back.
3. If MAC was already installed and you disable/remove the Facebook Container add-on, any website can be assigned(eg. Wikipedia) to the "Facebook" container.
   Moreover, after re-enabling/re-installing the add-on, you can navigate to the previously assigned website in the "Facebook" container.
4. If you are logged on messenger.com, you install Facebook Container and after you change the focus back to messenger tab and you restart the browser. At the browser start up the messenger tab is not reloaded but you can choose to continue to log in. Doing this will leave show you a page not found error.

QA recommendation

The v1.3.0 build will clearly bring more tracking protection for users. However, we suggest the following actions:

• Add the extra domains found in our issues, at least "cdn.fbsbx" domain is opened in a normal tab when downloading a file from Messenger  #102, to avoid any tracking complaints from the users.
• Fix new found issue The "web.whatsapp.com" page doesn't open in a Facebook Container if the website was visited before installing Facebook Container #101 since it could be easily encountered by the users.
• Include also Facebook links opened from 3rd party apps while the browser is closed will not be loaded in a Facebook container tab #61 and Facebook share tabs are wrongly opened in 1st position of the tab strip #73 since they have PR’s and are treating some cases that are easily encountered by users.

[groovecoder]

Thanks @SoftVision-PaulOiegas ... I'll check these out later today to see how many I can roll into 1.3.0.

[stoically]

Regarding the "Other observed scenarios"

1. First navigation to facebook.com in No Container: In this case the initial navigation to facebook.com is reported from MAC as not assigned, since only www.facebook.com is assigned. Facebook Container then proceeds to reopen in Facebook Container. After that the redirect to www.facebook.com happens - this request will be ignored from Facebook Container since MAC reports that it's assigned. Now MAC jumps in and gives the choice between Facebook Container and assigned container.

   First navigation to www.facebook.com in No Container: MAC reports assignment and thus Facebook Container ignores the request. MAC proceeds to give the choice between No Container and assigned container.

   Possible workaround: If the incoming request doesn't start with www., then Facebook Container should check for MAC assignment with and without www.

   Related: Contain-facebook breaks multi-facebook accounts contianer's prompt #96

2. Expected behavior, see: Disabling extension closes all container tabs without warning multi-account-containers#864

3. After disabling Facebook Container can't intercept requests anymore and thus the Facebook Container is just like any other permanent container - so that's expected behavior. And if the Facebook Container Add-on is then enabled again, we have to respect MAC assignments or we will run into endless loops

   Possible workaround: Let MAC check if Facebook Container is installed and enabled; if so let MAC ignore all requests inside the Facebook Container so the Facebook Container Add-on can handle them. Also MAC should ignore assignments to the Facebook Container in this case so the confirm page doesn't show the choice to open in Facebook Container (because that wouldn't work)

4. Would be fixed with Facebook links opened from 3rd party apps while the browser is closed will not be loaded in a Facebook container tab #61. The underlying problem here is, that navigations are not always "main_frame" from the API perspective, but instead the website loads and displays content dynamically (using e.g. XHR or fetch and changing URL using pushState or window.location)

[SoftVision-PaulOiegas]

Hi team,

We have verified today the new 1.3.0 build which doesn’t contain the “whatsapp.com” domain variations. We haven’t observed any other new issues and all the whatsapp domain variations are correctly opened in a normal tab.

QA recommendation

The removal of the whatsapp.com domain variations made most of the issues found yesterday to be no longer reproducible on 1.3.0. This made this build a good candidate for release.

However, we are still concerned about #102 and #103 issues, that are treating better privacy for messenger.com files download and Facebook login for Instagram.
But, since the fix for #103 proposed by Stoically is not helping, we suggest to add at least #102 to avoid any complaints from the messenger.com users.

[TanviHacks]

1.3.0 released so closing.