When I open PDF files from my university portal (Politecnico di Torino) and want to download them, I get inconsistent results using the download button in pdfjs vs. using Ctrl+S. Notably, the former works correctly and downloads a PDF, and the latter downloads a short HTML page (a Shibboleth error):

An error occurred while processing your request. Please contact your helpdesk or user ID office for assistance.

This service requires cookies. Please ensure cookies are enabled in your browser, then go back to your desired resource and try to login again.

Use of your browser's back button may cause specific errors that can be resolved by going back to your desired resource and trying to login again.

If you think you were sent here in error, please contact technical support

I could reproduce this on a clean Nightly, but not on release. It has also begun recently, I think with the update to 2020-05-22.

Unfortunately I don't have a publically-reproducible testcase, but I'll be happy to follow instructions to debug it.

Could you please provide an example that I can access having Politecnico di Torino login credentials (I should still have them).

Otherwise you can use mozregression https://mozilla.github.io/mozregression/ to identify a regression range where this broke, and from the list we can probably find the changed that caused this.

Any PDF file from "Materiale" will do. The file at https://file.didattica.polito.it/download/MATDID/32965627 likely works for any student; for other examples, log into didattica.polito.it, go to the "Materiale" tab, then pick any course and download a PDF (I picked "Advanced engineering thermodynamics" > 01NMFQD > Notes > "Notes of Numerical Modelling - vers. 04/03/20").

It seems that this will also work with a local file. I tried to reproduce this with a plaintext HTTP server (python3 -mhttp.server; I already had some cookies on localhost:8000), and Wireshark will show that:

• the first access to the page results in a GET request with cookies (and a specific Accept header, if it helps);
• downloading from pdfjs does not result in an additional request;
• downloading with Ctrl+S results in a new GET request with no cookies (and a generic Accept header).

The first request:

GET /filename.pdf HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Referer: http://localhost:8000/
Cookie: auth.strategy=local
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1

The second:

GET /filename.pdf HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Referer: http://localhost:8000/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site

It looks like related to first-party isolation, I confirmed this regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a55d8ca4738f9b51515959de087df55e5d5999d8&tochange=7e53b5398797485e8f326bde1fcb5820afcbc8a2

With pdf.js we apparently just save the cached entry? I don't see a request sent, only a safebrowsing check.

With CTRL+S I see this:
Request:
GET /download/MATDID/32965627 HTTP/1.1
Host: file.didattica.polito.it
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Referer: https://idp.polito.it/idp/profile/SAML2/Redirect/SSO
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site

Response:

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Thu, 28 May 2020 14:37:24 GMT
Content-Type: text/html
Content-Length: 138
Connection: keep-alive
Location: https://idp.polito.it/idp/profile/SAML2/Redirect/SSO?SAMLRequest=[...]
Expires: Wed, 01 Jan 1997 12:00:00 GMT
Cache-Control: private,no-store,no-cache,max-age=0
Strict-Transport-Security: max-age=15768000; includeSubDomains; preload
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block

and then this redirects another couple times...

Let me know if I can fetch more info or headers to help.

giul.mus, can I ask you to run an extra test? Do you mind to see if the PDF saving works with pref network.cookie.sameSite.laxByDefault=false?
I tried to reproduce the bug locally using a sameSite=none cookie, the second request (the CTRL+S one) receives the cookie correctly.
But if I have a sameSite=lax cookie, that request doesn't send cookie.
I suspect that bug 1639154 makes an existing bug more visible.

In that case I get yet another page, this time the login page for my university - the same I would get if I were to visit the link without being logged in.

I tested the patch and it fixes the problem.

https://hg.mozilla.org/mozilla-central/rev/57d24342399d

The patch landed in nightly and beta is affected.
:baku, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

It's not. Beta is not affected. This issue happens because in nightly we ere experimenting with network state isolation.