View Page Source does not work when containers are used

[abextm]

Before submitting a bug report

• I updated to the latest version of Multi-Account Container and tested if I can reproduce the issue
• I searched for existing reports to see if it hasn't already been reported

Step to reproduce

1. Navigate to a page without a default container set
2. Right click -> View Page Source
3. A new tab opens, showing the container selection page
4. Select a container
5. You are now back on the same page you were before, not its view-source: variant

Actual behavior

The rendered page opens instead of its source

Expected behavior

The view-source: page opens in the same container as before.

Additional informations

Navigating by editing the URL in an existing tab works.

In general, it would be nice if opening new tabs would use the same container as the referring tab if they shared a domain.

Provide a copy of Troubleshooting Information page (optional)

Application Basics
------------------

Name: Firefox
Version: 120.0a1
Build ID: 20230929213558
Distribution ID:
Update Channel: nightly
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/120.0
OS: Linux 6.5.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 23 Sep 2023 22:55:13 +0000
OS Theme: Minwaita / Minwaita
Multiprocess Windows: 2/2
Fission Windows: 2/2 Enabled by default
Remote Processes: 42
Enterprise Policies: Inactive
Google Location Service Key: Found
Google Safebrowsing Key: Found
Mozilla Location Service Key: Found
Safe Mode: false
Memory Size (RAM): 62.7 GB
Disk Space Available: 230 GB

Crash Reports for the Last 3 Days
---------------------------------

Nightly Features
----------------

Name: Firefox Screenshots
Version: 39.0.1
ID: [email protected]

Name: Form Autofill
Version: 1.0.1
ID: [email protected]

Name: Picture-In-Picture
Version: 1.0.0
ID: [email protected]

Name: Web Compatibility Interventions
Version: 119.0.0
ID: [email protected]

Name: WebCompat Reporter
Version: 1.5.1
ID: [email protected]

Remote Features
---------------

bug-1705528-rollout-ongoing-fission-nightly-rollout-clone-nightly-90-100: active
rollout-monitor-v2-1505837: active
CSV Import (Nightly Rollout): (enable-csv-import)
Nightly-only Glean wall-clock event timestamps: (control)
Product Insight Telemetry via Server Knobs - Rollout - 100%: (control-rollout)
Rollout - 100% - Experiment for Additional Metrics for Product Insights - New: (control-rollout)
SERP Ad Telemetry Validation Rollout: (control)
Upgrade Spotlight Rollout: (treatment)

Remote Processes
----------------

Type: Isolated Web Content
Count: 34

Type: Preallocated
Count: 3

Type: RDD
Count: 1

Type: Socket
Count: 1

Type: Extension
Count: 1

Type: Privileged About
Count: 1

Type: Sandboxed IPC Actor
Count: 1

Add-ons
-------

...

Name: Firefox Multi-Account Containers
Type: extension
Version: 8.1.2
Enabled: true
ID: @testpilot-containers

...

[dannycolin]

If it shows the container selection page, it means the domain is assigned to a container. Try ticking the "Remember my decision" and clicking on the right button if you want the view-source to open in the same container. If You want to open it outside a container, follow the instructions in https://support.mozilla.org/en-US/kb/containers#w_manage-site-assignments to remove an assignment and make sure the domain hasn't been accidentally assigned to a container.

[abextm]

The Remember my decision button does not work (#2294), but even if it did it would still break in the situation that I don't want the domain assigned to a container by default

[dannycolin]

The Remember my decision button does not work (#2294), but even if it did it would still break in the situation that I don't want the domain assigned to a container by default

It does work but it's meant to only work with the right (blue) button. Also, if you see the confirmation page, that means Multi-Account Containers considers the domain to be assigned to a container.

Cuurently, the only solution is to remove the domain from the assigned domain list as mentioned in the documentation I shared and manually (re)open in container the page.

There are other tickets on file that request this feature:

• Always open this site in.. with multiple choice #2235
• Feature Request: Ask in which container to open a link or new tab #2001

[abextm]

Strictly, the Remember my decision button does not work because it does not remember my decision, but that is neither here nor there. In this case I want it to prompt me when I open a new tab for this domain, which is what causes this to not work.

[dannycolin]

Strictly, the Remember my decision button does not work because it does not remember my decision, but that is neither here nor there.

What I meant is it works as intented by the developers who implemented it. However, I strongly agree the UX is confusing and this is why I shared a link to the appropriate bug report to thumbs up/follow.

In this case I want it to prompt me when I open a new tab for this domain, which is what causes this to not work.

Same here. This would be the second bug report link I shared.

I completely understand the annoyance of this limitation but my goal, here, was to offer help in case it was caused by a different bug and also inform you about the possible solutions to workaround this in the meantime.

Since your issue is related to this two other bug reports, I think we can close this bug as a duplicate of them. Sorry again that I can't help you more with this. As a last suggestion, try looking on https://addons.mozilla.org/en-US/firefox/ in case there's another addon that offers this feature.

[abextm]

This bug is about the existing container selection page in this addon breaking this form of navigation. The bad UX is just a contributing factor. This is not a request for an alternate or modified container selection page, like the 2 issues you linked, though they would make this bug have lower impact.

[Cimbali]

The reported bug is just that view-source: in the URL is lost when redirecting, no? I can’t reproduce with your steps as opening the source page always opens in the same container. However, I can reproduce with:

• open a new tab without container
• using a domain that is assigned to a container, go to view-source:https://<domain>.com/
• redirect happens (automatically or by validating on redirect page), the containerless tab is closed and a container tab is opened
• the URL in the container tab is now https://<domain>.com/ instead of view-source:https://<domain>.com/

[abextm]

Here is the bug in the op (on a fresh profile):

2023-10-15__01_38_23.mp4

And @Cimbali 's bug

2023-10-15__01_39_10.mp4