1649054 - AMO Original TAB goes Blank when creating a Container for external links

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect)

Description

[Sylvain]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

AMO Original TAB goes Blank when creating a Container for external links.

1. Install Temporary Containers
   https://addons.mozilla.org/en-CA/firefox/addon/temporary-containers/
2. Optionally install Multi-Account-Container (also affected sometimes)
3. In TC Addon options, Enable Automatic Mode (in General TAB)
4. In TC Addon Options, Enable Global Isolation on Navigation to Different Domain (in Isolation TAB)
5. Go on AMO to some Addon webpage
6. Click an external link

You can also trigger this with MAC installed and set to always open AMO into a preferred container. Then all you have to do is select an unloaded AMO tab which was previously opened in a different/no container, and TC will re-open the tab into the preferred MAC container, causing the issue.

Actual results:

When you are on AMO with Temporary Containers running, and set to automatically create a temporary container (or a permanent container if you have this set in MAC for the target domain) when navigating outside of a TAB's domain, then when you click on an outgoing link the following happens:

a) Current TAB is CLEARED of content
b) A new TAB is opened for outgoing.moz
c) a second new TAB is opened to the target domain

The issue here is that the original AMO TAB gets CLEARED. It looses all its content and the address bar is erased, but the TAB's TITLE remains the same. If you close this TAB and re-open it via History -> Recently Closed TABs, then you can recover it.

Expected results:

The AMO TAB should not clear itself. I'm not sure what's going on but it seems specific to AMO. I've also had an AMO TAB clear itself when I reloaded it (from Inactive, i.e. after restarting Firefox) and it was, at the time, in No Container, and it gets re-opened into my Work Container automatically (as I have since asked MAC to open AMO in the Work container).

Comment 1

[Alexandra Martin]

Hi,

Thank you for submitting the bug report. Testing was done in Windows 10 x64 bit and MacOS 10.14 with Nightly 80.0a1 (20200702214948), Beta 79.0b3 (20200703001609), Release 78.0.1 (20200630195452) and Release 77 (20200528194502).

According to the description, only point a: "Current TAB is CLEARED of content" seems to be the issue, which was reproduced on Release 77 and 78.0.1. A regression range was found on the issue, narrowing it down to https://bugzilla.mozilla.org/show_bug.cgi?id=1583700 (2020-07-03T17:11:28.349000: DEBUG : Found commit message: Bug 1583700 - Listen for DocumentChannel's on-opening-request as well as HTTP's in ExtensionPolicyService. r=jya), with this differential revision: https://phabricator.services.mozilla.com/D50118.

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f748a3d2cdf108e9443fd15332efe477c7c398a9&tochange=25b533bff4051e6a8177bbc83eed49ac460e109e

On Beta 79.0b3 and Nightly 80.0a1 point a was not reproduced, only points b and c (which seems to be the expected behaviour after installing the Temporary Containers add-on). After performing a bisection the following result was found which may be responsible for the possible fix:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1626362 (2020-07-03T15:08:31.282000: DEBUG : Found commit message: Bug 1626362 - Don't return a failure from nsDocumentOpenInfo::OnStartRequest if we decide to handle the response with the external helper app and then fail. r=nika

The WPT a-download-click-404.html requires this behaviour for links with the download attribute, and this is also the current behaviour for Content-Disposition: Attachment (see bug 1604308).

This previously worked because the parent process version of nsDocumentOpenInfo failed (with NS_ERROR_FILE_NOT_FOUND), but the error code was discarded and we forwarded the channel to the content process. The content process version then would then return NS_ERROR_WONT_HANDLE_CONTENT since the load requires downloading, but we don't allow that in the content process. This new error code is one that doesn't have an associated error page (unlilke the original error), so was silently discarded.).

The differential revision for this is: https://phabricator.services.mozilla.com/D81014.

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=030fc276c426f2ffea2404eda190f1f1b8aed1cf&tochange=d25dfe67b69e934b668c0390b2bb6fd2292387fa

Comment 2

[Sylvain]

Good day.

Point A is indeed the only problem (AMO TAB gets Cleared). Will wait for release 79 and test again, then report back. Thank you much for your attention to this.

FF is evolving so much these days; it has been a long time since I've looked forward to every single revision and wanted them to go faster, but recently this is just how I feel. Good job Mozilla!

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Fixed by bug 1626362 from the sounds of it.