1824658 - Resend request is blocked by Opaque Request Blocking in early beta

Status: RESOLVED FIXED

(DevTools :: Netmonitor, defect, P2)

Description

[Julian Descottes [:jdescottes]]

We are starting to get reports of the "resend request..." feature failing because of Opaque Request Blocking, which got enabled on Beta with Bug 1821682.

Currently one report on discourse: https://discourse.mozilla.org/t/resend-request-in-network-tab-is-immediately-blocked/112551

Apparently, the user is trying to resend a request without doing any modification, but ORB makes the request fail.

Comment 1

[Julian Descottes [:jdescottes]]

Bomsy, can you try to test edit and resend on Nightly and see if you can find any STRs that would work here? From discourse it seems the main difference between the original and the resent request was the initiator.

Comment 2

[Nicolas Frandeboeuf]

Hi!

I can reproduce on Nightly 114.0a1 (2023-04-19) (64-bit).

Here are the STR:

1. Open https://jsonformatter.org/json-parser with the devtools open and the network panel open
2. Filter on "gvl.json" (I always reproduce on JSON only)
3. Right-click and click on "Edit & resend"

What happens:

A NS_ERROR_FAILURE is displayed in the "Transfer" column, no response or anything else.

Expected:

The json to be loaded

In the browser console a wild warning appears (sorry, it's in French):

La ressource à l’adresse « https://the.gatekeeperconsent.com/cmp/gvl.json?v=3&lang=en » a été bloquée par OpaqueResponseBlocking. Raison : « Javascript validation failed ».

Comment 3

[Julian Descottes [:jdescottes]]

I didn't mention it in this bug, but the feature is driven by the preference browser.opaqueResponseBlocking.javascriptValidator which is only true on "early beta" and nightly. So if you are on the beta channel and you want a saner developer experience, you might want to turn this to false for now.

Comment 4

[Sean Feng [:sefeng211]]

Is the STR still working? I can't load the site.

I also don't understand why the initial request succeeded but the re-send request failed. Was it because the initial request was not a no-cors request and the re-send request was?

Comment 5

[Nicolas Frandeboeuf]

Hi,

the STR are still working yes.

Comment 6

[Sean Feng [:sefeng211]]

Hmm, now the site loads, but I don't see gvl.json in the network tab

Comment 7

[Julian Descottes [:jdescottes]]

FWIW, I could reproduce with the STRs from comment 2.

(In reply to Sean Feng [:sefeng] from comment #4)

Is the STR still working? I can't load the site.

I also don't understand why the initial request succeeded but the re-send request failed. Was it because the initial request was not a no-cors request and the re-send request was?

Indeed the initial request has Sec-Fetch-Mode: cors, but the re-sent request has Sec-Fetch-Mode: no-cors!

Comment 8

[Sean Feng [:sefeng211]]

Indeed the initial request has Sec-Fetch-Mode: cors, but the re-sent request has Sec-Fetch-Mode: no-cors!

I see! I assume this is done intentionally, so If https://searchfox.org/mozilla-central/rev/4e7b319091f2f9eddde7bb6810918dd5de23b709/netwerk/base/nsILoadInfo.idl#553 is set, ORB won't block it. Should we consider to set it to true for these re-send requests?

Comment 9

[Hubert Boma Manilla (:bomsy)]

(In reply to Sean Feng [:sefeng] from comment #8)

Indeed the initial request has Sec-Fetch-Mode: cors, but the re-sent request has Sec-Fetch-Mode: no-cors!

I see! I assume this is done intentionally, so If https://searchfox.org/mozilla-central/rev/4e7b319091f2f9eddde7bb6810918dd5de23b709/netwerk/base/nsILoadInfo.idl#553 is set, ORB won't block it. Should we consider to set it to true for these re-send requests?

Sure. i'll try that and see ..and feedback. Thanks

Comment 10

[Hubert Boma Manilla (:bomsy)]

Attachment: Bug 1824658 - [devtools] Resend requests should inherit principals r=jdescottes,sefeng

For some feedback.

Switching away from having a null principal to inheriting the principal, this seems to stop
the ORB js validator from blocking the request.

But wondering if this is an acceptable approach.

Setting isInDevToolsContext on the channel did not seem to work.

Comment 11

[Julian Descottes [:jdescottes]]

Let's check the status before Bomsy's PTO tomorrow

Comment 12

[Nicolas Frandeboeuf]

(In reply to Julian Descottes [:jdescottes] from comment #3)

I didn't mention it in this bug, but the feature is driven by the preference browser.opaqueResponseBlocking.javascriptValidator which is only true on "early beta" and nightly. So if you are on the beta channel and you want a saner developer experience, you might want to turn this to false for now.

BTW, I tried that and got no response from the resent request this time: "Stratégie de référent : la stratégie de référent la moins restrictive « unsafe-url » est ignorée pour la requête intersite : https://the.gatekeeperconsent.com/cmp/gvl.json?v=3&lang=fr"

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d042f945d03e
[devtools] Resend requests should inherit principals  r=jdescottes,sefeng,devtools-reviewers

Comment 14

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/d042f945d03e