Resend request is blocked by Opaque Request Blocking in early beta
Categories
(DevTools :: Netmonitor, defect, P2)
Tracking
(firefox118 fixed)
Tracking | Status | |
---|---|---|
firefox118 | --- | fixed |
People
(Reporter: jdescottes, Assigned: bomsy)
References
(Blocks 1 open bug)
Details
(Whiteboard: [devtools-triage])
Attachments
(1 file)
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.
Reporter | ||
Comment 1•1 year ago
|
||
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•9 months ago
|
||
Hi!
I can reproduce on Nightly 114.0a1 (2023-04-19) (64-bit).
Here are the STR:
- Open https://jsonformatter.org/json-parser with the devtools open and the network panel open
- Filter on "gvl.json" (I always reproduce on JSON only)
- 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 ».
Reporter | ||
Updated•9 months ago
|
Reporter | ||
Comment 3•9 months ago
|
||
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•9 months ago
|
||
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•9 months ago
|
||
Hi,
the STR are still working yes.
Comment 6•9 months ago
|
||
Hmm, now the site loads, but I don't see gvl.json
in the network tab
Reporter | ||
Comment 7•9 months ago
|
||
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•9 months ago
|
||
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?
Assignee | ||
Comment 9•9 months ago
|
||
(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
Assignee | ||
Comment 10•9 months ago
|
||
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.
Updated•9 months ago
|
Reporter | ||
Comment 11•9 months ago
|
||
Let's check the status before Bomsy's PTO tomorrow
Comment 12•9 months ago
|
||
(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"
Updated•9 months ago
|
Updated•9 months ago
|
Comment 13•9 months ago
|
||
Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d042f945d03e [devtools] Resend requests should inherit principals r=jdescottes,sefeng,devtools-reviewers
Comment 14•9 months ago
|
||
bugherder |
Assignee | ||
Updated•8 months ago
|
Description
•