Closed Bug 1824658 Opened 1 year ago Closed 10 months ago

Resend request is blocked by Opaque Request Blocking in early beta

Categories

(DevTools :: Netmonitor, defect, P2)

defect

Tracking

(firefox118 fixed)

RESOLVED FIXED
118 Branch
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.

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.

Flags: needinfo?(hmanilla)

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 ».

Whiteboard: [devtools-triage]

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.

Blocks: orb

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?

Hi,

the STR are still working yes.

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

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!

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?

(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

Flags: needinfo?(hmanilla)

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.

Assignee: nobody → hmanilla
Status: NEW → ASSIGNED

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

Severity: -- → S3
Flags: needinfo?(hmanilla)
Priority: -- → P2

(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"

Attachment #9346651 - Attachment description: Bug 1824658 - [devtools] Change the resent request to inherit the principal r=jdescottes,sefeng → Bug 1824658 - [devtools] Set the isInDevToolsContext flag for new and resend requests sent from the netmonitor r=jdescottes,sefeng
Attachment #9346651 - Attachment description: Bug 1824658 - [devtools] Set the isInDevToolsContext flag for new and resend requests sent from the netmonitor r=jdescottes,sefeng → Bug 1824658 - [devtools] Resend requests should inherit principals r=jdescottes,sefeng
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d042f945d03e
[devtools] Resend requests should inherit principals  r=jdescottes,sefeng,devtools-reviewers
Blocks: 1847498
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 118 Branch
Flags: needinfo?(hmanilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: