1811377 - "Blocked Page" with no explanation in F12 console, probably related to 'COEP: require-corp'

Status: UNCONFIRMED

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

Description

[Jakob Bohm]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

Whenever Firefox displays the "Blocked page" in an iframe (or elsewhere), the reason should be explicitly and clearly logged in the debugger console.

In my specific case I was testing some webpage code to load a youtube video in an iframe, that code works on other pages of the site, but not in this one case. So I opened the Firefox debugger with F12 to see why the video was replaced with "Blocked page". As I continue to debug the web page, the specific situation will hopefully disappear long before anyone reads this bug about the error reporting.

Actual results:

The iframe shows "Blocked Page An error occurred during a connection to www.youtube.com."
The F12 console shows "This error page has no error code in its security info aboutNetError.mjs:557:13"

Expected results:

The F12 console should show, explicitly, why and how something was blocked, not a message about the error handling code itself being buggy.

Ideally, anytime code anywhere blocks access to any page element, for any reason, that reason, with all applicable details should be explicitly passed to the core function that actually stops loading the blocked stuff, and that core function itself should unconditionally log the details of the reason and the blocked request for debugger users to know. As these messages are destined for the debugger console, they can be in English and not localized.

Firefox component and extension authors should be encouraged to pass explanation strings whenever they block a request, but if they fail to do so, the core code should log what other piece of code failed to explain itself.

For example a log message might be (this example is for an iframe blocked by a CSP rule on the outer page):

"request to https://www.example.com/foo/bar.png as an iframe with referrer https://www.example.net/testpage.html blocked by mozcode:content-security-policy because "www.example.com doesn't match CSP rule "child-src: *.example.net" received from https://www.example.net/testpage.html"",

In the above example, "www.example.com doesn't match CSP rule "child-src: *.example.net" received from https://www.example.net/testpage.html"" is the string received from the part of Firefox that does CSP, and that part is (in the example only) named mozcode:content-security-policy

I don't know the specific structure of the Firefox code that handles blocked pages, so I cannot point to exactly what internal code would need to be improved, but telling developers and advanced users where and why an error condition is triggered is the least one should expect from any kind of debugger.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jakob Bohm]

Supplemental: Debugging showed that the page accidentally had the header "Cross-Origin-Embedder-Policy: require-corp", but youtube still doesn't set the needed permissive headers to work with that. However the bug in Firefox is that neither the browser error message nor the message in the debug consoles says that. Fortunately the Google Chrome debugger did give a clear message in its own roundabout way.

Comment 3

[Daniel Veditz [:dveditz]]

The F12 console should show, explicitly, why and how something was blocked, not a message about the error handling code itself being buggy.

Of course it should, but at the point the message-logging code was told to log an error with no error code what should it do? That message is a cry for help: it can't do its job, but it's trying. As you pointed out, elsewhere it does print out appropriate messages. Telling us it should do what it's trying to do doesn't at all help figure out what went wrong in this case, or even what this case is.

Thank you for the update in comment 2. Knowing that it is some condition to do with YouTube and a "require-corp" header at least gets us in the ballpark of the problem. I assume from your vagueness that the page with the problem isn't public, but maybe you could share the network headers the page was served with, and the HTML and/or JS code you used to embed YouTube?

[moving to DOM: Networking

Comment 4

[Jakob Bohm]

The error message in the log should at least be a human readable complaint that another XUL element blocked the retrieval without giving a reason, instead of an error message complaining about the error page and pointing to a line in aboutNetError.mjs

The webpage in question was https://www.wisemo.com/products/modules/iphone-ipad-and-ipod/, but with a different set of server headers, specifically the following (reconstructed, the Cross-Origin-Embedder-Policy header was removed server side before posting Comment #2 above):

HTTP/1.1 200 OK
Cache-Control: max-age=172800
Content-Type: text/html
Content-Encoding: gzip
Last-Modified: Tue, 17 Jan 2023 20:14:35 GMT
Accept-Ranges: bytes
ETag: "80874151b02ad91:0"
Vary: User-Agent, Referer, Origin, Accept-Encoding
Server: Microsoft-IIS/8.5
Access-Control-Allow-Origin: https://www.wisemo.com
Strict-Transport-Security: max-age=31536000
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Content-Security-Policy: [Line breaks inserted to make bug report more readable]
 default-src wisemo.com wisemo.com:* *.wisemo.com *.wisemo.com:* wisemo.net wisemo.net:* *.wisemo.net *.wisemo.net:* wisemo.mobi wisemo.mobi:* *.wisemo.mobi *.wisemo.mobi:* wisemo.eu wisemo.eu:* *.wisemo.eu *.wisemo.eu:* wisemo.dk wisemo.dk:* *.wisemo.dk *.wisemo.dk:* data: 'unsafe-inline' 'unsafe-eval' ;
 child-src wisemo.com wisemo.com:* *.wisemo.com *.wisemo.com:* wisemo.net wisemo.net:* *.wisemo.net *.wisemo.net:* wisemo.mobi wisemo.mobi:* *.wisemo.mobi *.wisemo.mobi:* wisemo.eu wisemo.eu:* *.wisemo.eu *.wisemo.eu:* wisemo.dk wisemo.dk:* *.wisemo.dk *.wisemo.dk:* *.youtube.com data: 'unsafe-inline' 'unsafe-eval' ;
 connect-src wisemo.com wisemo.com:* *.wisemo.com *.wisemo.com:* wisemo.net wisemo.net:* *.wisemo.net *.wisemo.net:* wisemo.mobi wisemo.mobi:* *.wisemo.mobi *.wisemo.mobi:* wisemo.eu wisemo.eu:* *.wisemo.eu *.wisemo.eu:* wisemo.dk wisemo.dk:* *.wisemo.dk *.wisemo.dk:* *.youtube.com data: 'unsafe-inline' 'unsafe-eval' ;
 font-src wisemo.com wisemo.com:* *.wisemo.com *.wisemo.com:* wisemo.net wisemo.net:* *.wisemo.net *.wisemo.net:* wisemo.mobi wisemo.mobi:* *.wisemo.mobi *.wisemo.mobi:* wisemo.eu wisemo.eu:* *.wisemo.eu *.wisemo.eu:* wisemo.dk wisemo.dk:* *.wisemo.dk *.wisemo.dk:* data: 'unsafe-eval' ;
 form-action 'unsafe-inline' 'self' https://test.checkout.dibspayment.eu/hostedpaymentpage/ https://checkout.dibspayment.eu/hostedpaymentpage/ ;
 frame-ancestors wisemo.com wisemo.com:* *.wisemo.com *.wisemo.com:* wisemo.net wisemo.net:* *.wisemo.net *.wisemo.net:* wisemo.mobi wisemo.mobi:* *.wisemo.mobi *.wisemo.mobi:* wisemo.eu wisemo.eu:* *.wisemo.eu *.wisemo.eu:* wisemo.dk wisemo.dk:* *.wisemo.dk *.wisemo.dk:* ; frame-src wisemo.com wisemo.com:* *.wisemo.com *.wisemo.com:* wisemo.net wisemo.net:* *.wisemo.net *.wisemo.net:* wisemo.mobi wisemo.mobi:* *.wisemo.mobi *.wisemo.mobi:* wisemo.eu wisemo.eu:* *.wisemo.eu *.wisemo.eu:* wisemo.dk wisemo.dk:* *.wisemo.dk *.wisemo.dk:* *.youtube.com data: wisemoguest: 'unsafe-inline' 'unsafe-eval' ;
 upgrade-insecure-requests ;
 worker-src wisemo.com wisemo.com:* *.wisemo.com *.wisemo.com:* wisemo.net wisemo.net:* *.wisemo.net *.wisemo.net:* wisemo.mobi wisemo.mobi:* *.wisemo.mobi *.wisemo.mobi:* wisemo.eu wisemo.eu:* *.wisemo.eu *.wisemo.eu:* wisemo.dk wisemo.dk:* *.wisemo.dk *.wisemo.dk:* data: 'unsafe-inline' 'unsafe-eval'
Referrer-Policy: unsafe-url
Date: Tue, 31 Jan 2023 10:09:46 GMT
Content-Length: 6543