1733274 - Modal error when right-click save button on StorySaver.net

Status: VERIFIED FIXED

(Core :: DOM: Networking, defect, P2)

Description

[B.J. Herbison]

Attachment: Screenshot of the error message.

Steps to reproduce:

1. Visit https://www.storysaver.net/ .
2. Enter "arminvanbuuren" as the account name and click Download! (or any other account with a story).
3. Complete the Captcha.
4. Right-click on Save as Video for a story and select Save Link As...

Expected:
4) Standard Save pop-up appears.

Actual:
4) Modal popup with the text:

The download cannot be saved because an unknown error occurred.
Please try again.
[OK]

Side note: No, it isn't "OK". It's an annoying situation. Why does Firefox keep insisting users say that everything is OK? Does Firefox have some issue where it constantly wants affirmation?

Right-click Save works with Google Chrome.

Issue observed with Firefox 92 and Nightly 94.

Comment 1

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

The site is timing out very often for me, so it was not trivial to reproduce, but I could reproduce it after a few tries.
The error comes from here:
https://searchfox.org/mozilla-central/rev/eecd2dd4ba630bea4ce103623a4bfb398065b64b/browser/base/content/nsContextMenu.js#1593,1604,1611
so it's an onStartRequest call for a failed request.

The request status is NS_ERROR_DOM_CORP_FAILED for me
Used to indicate that a resource with the Cross-Origin-Resource-Policy response header set failed the origin check.

I'm not sure why it'd work in Chrome though, I'll neeinfo kershaw from Netwerk to evaluate, or eventually forward, the question.

Comment 2

[Kershaw Chang [:kershaw]]

Eden, could you take a look? you probably know more CORP code than me.
I can only tell the error is coming from this line, which shows the origin of the channel https://scontent.cdninstagram.com is different than load info's https://www.storysaver.net/.

Comment 3

[Eden Chuang[:edenchuang]]

It seems that it triggers cross-origin resource fetching. However, the resource's CORP is "same-site" which means is not allowed for cross-origin fetching. Then we meet the network error. I will double-check if there is a bug in our CORP implementation.

Comment 4

[Kershaw Chang [:kershaw]]

(In reply to Eden Chuang[:edenchuang] from comment #3)

It seems that it triggers cross-origin resource fetching. However, the resource's CORP is "same-site" which means is not allowed for cross-origin fetching. Then we meet the network error. I will double-check if there is a bug in our CORP implementation.

The response header is:

[Parent 74062: Socket Thread]: I/nsHttp http response [
[Parent 74062: Socket Thread]: E/nsHttp   HTTP/2 302 Found
[Parent 74062: Socket Thread]: E/nsHttp   location: https://scontent.cdninstagram.com/v/t50.2886-16/88639615_2347906042012816_4944134342582634168_n.mp4?efg=eyJ2ZW5jb2RlX3RhZyI6InZ0c192b2RfdXJsZ2VuLjcyMC5zdG9yeS5kZWZhdWx0IiwicWVfZ3JvdXBzIjoiW1wiaWdfd2ViX2RlbGl2ZXJ5X3Z0c19vdGZcIl0ifQ&_nc_ht=scontent-otp1-1.cdninstagram.com&_nc_cat=104&_nc_ohc=lN29BrmIVfIAX-0E1f7&edm=ANmP7GQBAAAA&vs=17876945792542179_3548604875&_nc_vs=HBksFQAYJEdIX0lTQVdRcEpsNWFGY0lBTGlHY2t2OUY1MUVidXFIQUFBQRUAAsgBABUAGCRHTXdna1E0M1NCTUNnRmdCQUMzT2dXZ3JTVTljYnBrd0FBQUYVAgLIAQAoABgAGwGIB3VzZV9vaWwBMRUAACbyqcTBjv%2FkPxUCKAJDMywXQC4AAAAAAAAYEmRhc2hfYmFzZWxpbmVfMV92MREAdegHAA%3D%3D&_nc_rid=370a9b483a&ccb=7-4&oe=615EB49B&oh=0d7fb8f08be773236b3daab7f19acd02&_nc_sid=276363&_nc_vts_prog=1&vts=1
[Parent 74062: Socket Thread]: E/nsHttp   content-type: text/plain
[Parent 74062: Socket Thread]: E/nsHttp   content-length: 0
[Parent 74062: Socket Thread]: E/nsHttp   server: proxygen-bolt
[Parent 74062: Socket Thread]: E/nsHttp   x-fb-trip-id: 1425083115
[Parent 74062: Socket Thread]: E/nsHttp   date: Tue, 05 Oct 2021 08:51:27 GMT
[Parent 74062: Socket Thread]: E/nsHttp   cross-origin-resource-policy: same-origin
[Parent 74062: Socket Thread]: E/nsHttp   x-frame-options: DENY
[Parent 74062: Socket Thread]: E/nsHttp   alt-svc: h3=":443"; ma=3600,h3-29=":443"; ma=3600,h3-27=":443"; ma=3600
[Parent 74062: Socket Thread]: E/nsHttp   X-Firefox-Spdy: h2
[Parent 74062: Socket Thread]: E/nsHttp     OriginalHeaders
[Parent 74062: Socket Thread]: E/nsHttp   location: https://scontent.cdninstagram.com/v/t50.2886-16/88639615_2347906042012816_4944134342582634168_n.mp4?efg=eyJ2ZW5jb2RlX3RhZyI6InZ0c192b2RfdXJsZ2VuLjcyMC5zdG9yeS5kZWZhdWx0IiwicWVfZ3JvdXBzIjoiW1wiaWdfd2ViX2RlbGl2ZXJ5X3Z0c19vdGZcIl0ifQ&_nc_ht=scontent-otp1-1.cdninstagram.com&_nc_cat=104&_nc_ohc=lN29BrmIVfIAX-0E1f7&edm=ANmP7GQBAAAA&vs=17876945792542179_3548604875&_nc_vs=HBksFQAYJEdIX0lTQVdRcEpsNWFGY0lBTGlHY2t2OUY1MUVidXFIQUFBQRUAAsgBABUAGCRHTXdna1E0M1NCTUNnRmdCQUMzT2dXZ3JTVTljYnBrd0FBQUYVAgLIAQAoABgAGwGIB3VzZV9vaWwBMRUAACbyqcTBjv%2FkPxUCKAJDMywXQC4AAAAAAAAYEmRhc2hfYmFzZWxpbmVfMV92MREAdegHAA%3D%3D&_nc_rid=370a9b483a&ccb=7-4&oe=615EB49B&oh=0d7fb8f08be773236b3daab7f19acd02&_nc_sid=276363&_nc_vts_prog=1&vts=1
[Parent 74062: Socket Thread]: E/nsHttp   content-type: text/plain
[Parent 74062: Socket Thread]: E/nsHttp   content-length: 0
[Parent 74062: Socket Thread]: E/nsHttp   server: proxygen-bolt
[Parent 74062: Socket Thread]: E/nsHttp   x-fb-trip-id: 1425083115
[Parent 74062: Socket Thread]: E/nsHttp   date: Tue, 05 Oct 2021 08:51:27 GMT
[Parent 74062: Socket Thread]: E/nsHttp   cross-origin-resource-policy: same-origin
[Parent 74062: Socket Thread]: E/nsHttp   x-frame-options: DENY
[Parent 74062: Socket Thread]: E/nsHttp   alt-svc: h3=":443"; ma=3600,h3-29=":443"; ma=3600,h3-27=":443"; ma=3600
[Parent 74062: Socket Thread]: E/nsHttp   X-Firefox-Spdy: h2
[Parent 74062: Socket Thread]: I/nsHttp ]

The corp header is same-origin.
It looks like the problem is that the document (https://www.storysaver.net/) wants to load a resource at https://scontent-otp1-1.cdninstagram.com/, and the server returns a 302 with cross-origin-resource-policy: same-origin. Since the origin is not the same, the channel returned the error NS_ERROR_DOM_CORP_FAILED.

Comment 5

[:Gijs (he/him)]

Eden: is it actually correct to apply CORP to "save link as" requests? I kind of doubt that - it's basically the same as saying "copy this link and pass to curl", or "open in new tab and save the document", both of which work.

Comment 6

[Anne (:annevk)]

Valentin, if true this doesn't match the specification for Cross-Origin-Resource-Policy. It only applies to "no-cors" requests (i.e., when fetching subresources). A download is a "navigate" request. Could you take a look at this since you implemented this header?

(FWIW, we shipped this header two years ago in bug 1602363.)

Comment 7

[Valentin Gosu [:valentin] (he/him)]

Indeed, we also need to allow ExtContentPolicy::TYPE_SAVEAS_DOWNLOAD

Comment 8

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1733274 - Skip CORP check for TYPE_SAVEAS_DOWNLOAD r=Gijs

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/90b3f27d6c66
Skip CORP check for TYPE_SAVEAS_DOWNLOAD r=Gijs

Comment 10

[Anne (:annevk)]

When looking at that code I initially thought it would also end up applying to CORS requests, but there are tests for that and we pass them. It's weird that CORS_MODE_NO_CORS encompasses navigation requests, they really ought to have their own mode as they do in Fetch.

Tests are in https://github.com/web-platform-tests/wpt/tree/master/fetch/cross-origin-resource-policy. It seems that navigations are tested, but navigations that are downloads are not. Those might be trickier to test as well given that there's no test API to deal with downloads.

Comment 11

[:Gijs (he/him)]

(In reply to Anne (:annevk) from comment #10)

When looking at that code I initially thought it would also end up applying to CORS requests, but there are tests for that and we pass them. It's weird that CORS_MODE_NO_CORS encompasses navigation requests, they really ought to have their own mode as they do in Fetch.

CORS, mixed content and downloads / "save page as" are fun, fwiw - x-ref bug 1668530.

Comment 12

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/90b3f27d6c66

Comment 13

[Eden Chuang[:edenchuang]]

Attachment: Bug 1733274 - Exclude SaveAsDownload requests from CORP checking. r=kershaw

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1602363

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Is this something we should consider backporting to ESR91?

Comment 16

[Valentin Gosu [:valentin] (he/him)]

I think the patch is simple enough that backporting it should be OK.

Comment 17

[Valentin Gosu [:valentin] (he/him)]

Comment on attachment 9247539 [details]
Bug 1733274 - Skip CORP check for TYPE_SAVEAS_DOWNLOAD r=Gijs

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration:
• User impact if declined: Users could be prevented from downloading files because of CORP errors.
• Fix Landed on Version: 95
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9247539 [details]
Bug 1733274 - Skip CORP check for TYPE_SAVEAS_DOWNLOAD r=Gijs

Approved for 91.5esr.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/a4283d730e7c

Comment 20

[Catalin Sasca, Desktop QA [:csasca]]

I wasn't able to reproduce the error message on Firefox 92.0.1 nor 94.0a1 (2021-09-29) under macOS 12.0.1, Ubuntu 20 or Windows 10 by following the exact steps from Comment 0.

Verified though that the videos downloads as expected after the fix on Firefox 95.0.2 and ESR 91.5.0 under the same systems.

Just to be extra sure, B.J. can you verify too the fixes on Firefox 95.0.2 and ESR 91.5.0? Thank you!

Comment 21

[B.J. Herbison]

I don't have the ESR, but I used Firefox 95.0.2 and the problem is fixed.