Created attachment 8930064 [details] firefox-blocked-iframe-load.tar.gz User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce: 1. Install the attached extension (both in Chrome and Firefox. 2. A new tab should be opened to a page with two iframes. 3. Open the developer tools for the tab and have a look in the console. Actual results: In Firefox a console message is logged for only the iframe which wasn't blocked by the extension. The iframe that was blocked has the location of `about:blank`. In Chrome a console message is logged for both iframes. The iframe that was blocked has the location of `chrome-error://chromewebdata/`. Expected results: We expected the load event to fire for the blocked iframe in both Firefox and Chrome. In Firefox we expected the frame's location to be `about:neterror`. Notes: - Without the load event firing Adblock Plus does not know that the blocked iframe should be hidden, so the user ends up with empty iframes littering the page. See the related Adblock Plus issue https://issues.adblockplus.org/ticket/6051
Sorry forgot to mention I'm running Debian Buster, Chrome 62 and Firefox 57.
For reference, the Adblock Plus code in question is a work-around that is necessary because of bug 1210990.
Component: DOM: Service Workers → WebExtensions: Request Handling
Product: Core → Toolkit
This is the expected behavior. When you block a request that early in the cycle, the frame never navigates, and the initial about:blank document remains loaded.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
Yes, we got this. The point is: in Chrome there is a navigation for blocked frames, to chrome-error://chromewebdata/. This is consistent with frames not loading due to name resolution errors and such. It would make more sense if blocked frames navigated to about:neterror in Firefox (I am pretty sure that this was requested for nsIContentPolicy a long time ago but I cannot find the bug).
Well, feel free to reopen and move to DocShell if it's that important to you, but the webRequest side of this works as expected. I'm not sure how loading about:neterror would help you, though. Aside from being an unreliable implementation detail, you shouldn't actually be able to access the URL of a cross-origin iframe, in that case, and the implementation of neterror pages actually tries to hide the underlying about:neterror document URI from external consumers, anyway.
As mentioned in the description, all we care about is a "load" event, we don't need to access the contents. That's the only way for us to identify the DOM element corresponding with the frame we just blocked.
Status: RESOLVED → REOPENED
Component: WebExtensions: Request Handling → Document Navigation
Product: Toolkit → Core
Resolution: INVALID → ---
You need to log in before you can comment on or make changes to this bug.