1463365 - File -> Save Page As... from inside a container saves an out-of-container version

Status: RESOLVED WORKSFORME

(Core :: DOM: Security, defect, P3)

Description

[Chris Midgley]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180517141400

Steps to reproduce:

1. Create a container
2. Inside the container, log in to a site
3. Navigate to a page that displays different content to logged-in users.
4. Save the page using File -> Save Page As or Ctrl-S.


Actual results:

The saved page is the one that would be displayed to logged-out users.


Expected results:

The saved page is the one seen in the browser.

This is what happens if you use Right-click -> Save Link As, but this is inaccessible when editing a URL directly, and trying to save the resulting page.

Comment 1

[laszlo.bialis]

Hi!

I've tried to reproduce the issue mentioned above but without success. 
I've used Beta version 61.0b6 Build ID:20180517141400 and latest Nightly 62.0a1 Build ID:20180525102548 on Win10 x64.

Could you give us a screen recording on what happened (you can use this app for screen recording https://www.screenpresso.com/)?

Comment 2

[Chris Midgley]

Hi,

I've also failed to reproduce it at home, using the GitHub main page. It's evidently not as clear-cut as I thought it was. I'll need to wait until I go back to work on Tuesday to check more.

I can't show the exact site because it contains confidential information, but the issue occurred when trying to download a text/plain page in a container from a site that I'd set to only open in that container (and that I wasn't logged in to outside the container). I can't think of any text/plain pages that show me different content when I'm logged in that I can access from home -- do you know of any?

Thanks for your help.

Comment 3

[Chris Midgley]

The exact failure case originally was attempting to Save Page inside a container from the raw version of a GitLab-hosted .feature file. I have reproduced this. Saving the View Source page also fails. Both of these have type text/plain, which is the primary difference I can see between this and a standard webpage.

I've succeeded when saving a standard webpage from work. I can save a webpage as a text file, and this also succeeds. I can save the source of a standard webpage (text/html).

Comment 4

[laszlo.bialis]

I've cloned the issue on GitHub, as the issues related to containers are discussed there. I'm assigning a component and will copy here any response I'll get regarding the issue.

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

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

Save As serializes the DOM as it exists (including any changes made by script), so it should save what's actually shown… except that for the “Complete Document” mode, subresources that aren't frames (images, stylesheets, script, etc.) are effectively re-downloaded.  This doesn't necessarily mean they'll be re-requested over the network instead of cached, but it's a new transaction, and nsWebBrowserPersist is very old code that might not be handling container information (OriginAttributes) correctly. 

Also, it doesn't remove script from the document, so it all gets run again when the saved page is reloaded.  (I assume this seemed more reasonable in the Netscape 4 era than it does today.)  That could also be causing problems, if the page is trying to do some kind of dynamic content generation.

And, if I recall correctly, nsWebBrowserPersist doesn't handle URLs inside stylesheets, so those aren't saved and would be re-fetched.

Comment 6

[:Gijs (he/him)]

bug 1469916 makes the crufty old webbrowserpersist code use principals, which contain the usercontextid/container information, so that'll help here.

Comment 7

[:Gijs (he/him)]

I believe this should be fixed on Nightly through bug 1469916 (except, as comment #5 notes, that if you open the saved page in some other container, any resources sourced via a stylesheet (x-ref bug 115107) or JS will be fetched in whatever container you use to open the page - but that seems expected behavior to me: at that point, it's just an arbitrary page that you're loading, and we should respect the container you load it in). Jonathan, can you verify?

Comment 8

[Jonathan Kingston [:jkt] he/him]

This seems to be working as expected for me. Obviously the opened page doesn't load in the container so the JS could do some things that break the page again but as Comment 5 suggests saved page output isn't perfect for many reasons.