1578134 - Cmd/Ctrl+S doesn't save PDF but HTML login document when certain cookie settings are enabled

Status: VERIFIED WORKSFORME

(Firefox :: Protections UI, defect, P5)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0 ID:20190829214656

I have seen this already for a while, and wonder if that actually is some kind of regression. I'm fairly sure that hitting Cmd/Ctrl+S when having a PDF page open inside the internal PDF viewer, formerly the PDF was saved and not the HTML which links to the PDF document.

Steps to reproduce:

1. Open some PDF file
2. Click the save button inside the PDF viewer => PDF is saved
3. Hit Cmd/Ctrl + S => the HTML is saved

While step 2 works, we should also make sure that pressing the usual shortcut saves the PDF correctly to disk. Currently this is kinda misleading because the proposed filename in the save as dialog is still .pdf, but then it produces invalid PDF files.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It's not actually any PDF but some specific ones behind a login.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

So I nailed this problem down to the following preference:

network.cookie.cookieBehavior

When it's value is 1 which means blocking any kind of tracking cookies, the command shortcut doesn't work, and instead of printing the document the login form is saved.

Actually I'm not sure why for the given website the login cookie is considered a third-party cookie, given that it comes from the exact same website.

The only thing is that the session cookie is set as domain cookie, but the website runs on a subdomain.

Comment 3

[Johann Hofmann [:johannh]]

1 means blocking third party cookies not tracking cookies. This is definitely not a bug with anti-tracking code, it sounds like an issue with either the site of the PDF viewer.

Comment 4

[Brendan Dahl [:bdahl]]

If the bug can be reproduced changing the above pref, it seems the issue is with tracking protection. Nothing that I know of has changed recently with how pdf.js saves anything.

Could tracking protection be getting confused with pdf.js? PDF.js is loaded from a resource url, but maintains the original channel url.

Comment 5

[Johann Hofmann [:johannh]]

I can't reproduce this, probably because of comment 1. Henrik (or anyone else who can reproduce this), do you have time to

• get a regression range with mozregression
• collect the console log from inside the pdf viewer?
• make the affected pdf accessible somehow?

to be clear, I also wouldn't consider breakage with third party cookies blocked a high priority in any case.

Thanks!

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I had a quick look (sorry I cannot do more today) and it started to happen between the 62.0 and 63.0b1 releases, which means at some point in Firefox Nightly 63. From the release notes I can find:

Added content blocking, a collection of Firefox settings that offer users greater control over technology that can track them around the web. In 63, users can opt to block third-party tracking cookies or block all trackers and create exceptions for trusted sites that don’t work correctly with content blocking enabled.

And that sounds totally related to this underlying problem. Johann is there a specific time range to check, which would help me to speed-up the regression test? Sorry but I cannot hand out this pdf given that it is an invoice. Also there is nothing specific visible in the browser console.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Actually I was able to check the nightly builds at least. Maybe this regression range between two Nightlies will help:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=987ea0d6a000b95cf93928b25a74a7fb1dfe37b2&tochange=cc3401e78e8bbae22e6dbc854e525ceae4923bcf

If not I will have to check more tomorrow.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I actually cannot find something in that list. But when I use the same range for Treeherder I get this list of 3 merges instead:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&fromchange=987ea0d6a000b95cf93928b25a74a7fb1dfe37b2&tochange=cc3401e78e8bbae22e6dbc854e525ceae4923bcf

Note that for the oldest there is a pdf.js update (bug 1473118).

Comment 9

[Johann Hofmann [:johannh]]

Blocking third party cookies has existed for a long time. We just changed how it's exposed to users (and we changed a bunch of internals as part of ETP but again, this bug isn't actionable without more information).

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As it looks like this happens for all sites where a PDF is offered for download behind a login. I can see the same eg for downloading bills from Amazon.

Comment 11

[Cristian Fogel [:cfogel]]

Any chance you could identify another website/pdf/link that presents this issue?
Don't have purchases on amazon accounts and tried with several sites-files but it appears to work ok.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

When I find the time I will have to create a minimized testcase maybe. But how did you exactly test? Which steps did you use? I wonder because I can always see this with a fresh profile and the given preference set.

Comment 13

[Cristian Fogel [:cfogel]]

Sorry for the really delayed response. Had trouble with tracking an alternative to Amazon.
Tried the STR from comment 0 for random PDF files that were not behind a login and PDF files even on GoogleDrive; but in their case swapping the preff value to 1 didn't appear to have any effect.

Comment 14

[Daniel Bodea [:danibodea]]

Considering the fact that we appear to have a hard time reproducing it, Henrik, can you help up by regression the issue yourself?

I will try to be as clear as possible about how to do it:

You need to install an application called mozregression through the terminal:
a. Install Xcode: https://apps.apple.com/us/app/xcode/id497799835?ls=1&mt=12
b. Install Brew:

1. Open terminal.
2. Input command: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
   c. Install Python3 with Brew:
3. Open Terminal.
4. Input command: brew install python3
   d. Install mozregression using python3:
5. Open terminal.
6. Input command: pip3 install mozregression
   More info on the installation:
   https://programwithus.com/learn-to-code/install-python3-mac/
   https://mozilla.github.io/mozregression/install.html
   https://pypi.org/project/mozregression/

You have to determine a build that reproduces the issue using the mozregression app:
a. Open terminal.
b. Open builds one by one using the command example:
mozregression --launch 2019-05-24
(it will open a nightly build with that date)
c. Test your issue and note down a date of a build that reproduced the issue.
Then you should also find a build date that does NOT reproduce it, using the same method.
(You need an older good date and a more recent bad date.)

You will use mozregression app to "bisect" builds that reproduce the issue by builds that do not reproduce it in search of the one build/changeset that introduced the issue, in the first place:
a. Open terminal.
b. Use the good and bad builkd date in the following command:
mozregression --good yyyy-mm-dd --bad yyyy-mm-dd
(where the yyyy-mm-dd is the date of the good/bad builds determined above)
c. Builds will open one-by-one, you will need to test each one of them and see whether the issue reproduces. If it reproduces, then you need to go to the terminal and write "bad" in the terminal window and if not, you need to select the "good" button. After your input, the current build will close and another will open for the bisection/regression process to continue.
d. When bisection is done, you will have the information in the terminal window; bisection may also fail due to not enough builds, but the logs can always be useful.
Copy the logs found in the terminal in a text file and attach it to this bug.

If there is still information you need regarding the regression process, please request information from me.
Thank you for your contribution!

Comment 15

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

I was able to reproduce this issue in last nightly build 74.0a1 (2020-01-22) (64-bit), regardless if network.cookie.cookieBehavior value is 1 or default (mine was 4, but tried both values)

Please see attachment added for further details. I first logged in to OneDrive, uploaded a pdf file and then I opened the pdf within FF. If trying to save the pdf file with the download button, the file is correctly saved as pdf, if using ctrl S shortcut, then it's saved as html.

If following these steps with a png file for example, then both Ctrl S and download button will save the png file correctly.

I tried these steps withing gmail, but this is not reproducible. I will try to find a good and bad date to perform the mozregression.

Best,

Clara

Comment 16

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: html.webm

Comment 17

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: file.webm

Comment 18

[Clara Guerrero ( Need Info Brindusa Tot Please)]

@Henrik I am unable to find a FF version in which the issue doesn't occur. I've tried random versions from 53.0a1 (2017-01-19) (64-bit) through 66.0a1 (2019-01-19) (64-bit) but it still occurs. Would you provide a video demonstrating how it did use to work correctly?

Thanks!
Clara

Comment 19

[Daniel Bodea [:danibodea]]

Considering the fact that this issue occurs as far back as in firefox53, we will assume that this is not a recent regression and that searching even further back is unnecessary unless requested again, assuming that a regression range could not be provided on the first try.

Comment 20

[Brendan Dahl [:bdahl]]

This should be fixed from changes in bug 1659753. If not, please re-open.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Yes, I can no longer reproduce this problem. Thanks!