1418975 - load event is not fired for iframes blocked by browser.webRequest.onBeforeRequest

Status: REOPENED

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

Description

[Dave Vandyke]

Attachment: 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

Comment 1

[Dave Vandyke]

Sorry forgot to mention I'm running Debian Buster, Chrome 62 and Firefox 57.

Comment 2

[Wladimir Palant]

For reference, the Adblock Plus code in question is a work-around that is necessary because of bug 1210990.

Comment 3

[Kris Maglione [:kmag]]

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.

Comment 4

[Wladimir Palant]

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

Comment 5

[Kris Maglione [:kmag]]

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.

Comment 6

[Wladimir Palant]

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.

Comment 7

[Tom S]

I found this again through bug 1584998 have been looking into this a little bit trying to understand what is going on.

Comment 8

[Tom S]

Attachment: Bug 1418975 - Dispatch load event for failed iframe loads

Comment 9

[Tom S]

Comment on attachment 9112527 [details]
Bug 1418975 - Dispatch load event for failed iframe loads

This seems to match Chrome's behavior. Chrome always fires the load event even for failed iframe loads.

I tried using an error event instead, but there seems to be special handling to forward load events from the iframe's window to the parent window in nsGlobalWindowInner::PostHandleEvent.

I haven't run any tests yet, but I suspect this is going to cause a number of test failures ... I am mostly just curious what we think of doing this.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 9112527 [details]
Bug 1418975 - Dispatch load event for failed iframe loads

So there are two separate questions:

1. Should a load event fire inside the document itself? For example, if the network drops during the pageload (before all the HTML is received), should it still fire a load event? I don't believe we do; does Chrome?

2. Should a load event fire on the iframe element (which we can do independently of the load event firing on the window inside the iframe)?

Really, this is a spec issue and we should get this sorted out there, ideally. I needinfo'd Anne on bug 1599256 already.

Comment 11

[Tom S]

Seems like Christoph implemented something like this for XFO in bug 1601887.

Comment 12

[Tom S]

I am interested in getting back to this. I am going to try and see if bug 1601887 can be extended to also cover iframes blocked by webextensions.