Open Bug 1418975 Opened 7 years ago Updated 5 months ago

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


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

57 Branch





(Reporter: kzar, Unassigned)


(Depends on 1 open bug)



(1 file, 1 obsolete file)

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

 - 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
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: Untriaged → Networking
Ever confirmed: true
Product: Firefox → Core
See Also: → 1210990
Component: Networking → DOM: Service Workers
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.
Closed: 7 years 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.
Component: WebExtensions: Request Handling → Document Navigation
Product: Toolkit → Core
Resolution: INVALID → ---
Priority: -- → P2

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

Assignee: nobody → evilpies

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.

Attachment #9112527 - Flags: feedback?(bzbarsky)
See Also: → 1552504
See Also: → 1599256

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.

Attachment #9112527 - Flags: feedback?(bzbarsky)
Attachment #9112527 - Attachment is obsolete: true

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

Depends on: 1601887

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.

Assignee: evilpies → nobody
Severity: normal → S3
Depends on: 1663633
You need to log in before you can comment on or make changes to this bug.