Opened 9 months ago

Last modified 8 months ago

#7305 closed defect

Requests blocked in whitelisted frame — at Version 9

Reported by: greiner Assignee:
Priority: P2 Milestone: Adblock-Plus-3.5.1-for-Chrome-Opera-Firefox
Module: Platform Keywords:
Cc: kzar, sebastian, Ross, arthur Blocked By:
Blocking: Platform: Chrome
Ready: yes Confidential: no
Tester: Ross Verified working: yes
Review URL(s):

https://gitlab.com/eyeo/adblockplus/adblockpluschrome/merge_requests/43
https://gitlab.com/eyeo/adblockplus/adblockpluschrome/merge_requests/49
https://gitlab.com/eyeo/adblockplus/adblockpluschrome/merge_requests/50

Description (last modified by greiner)

Environment

Ubuntu 16.04
Chrome 71
Adblock Plus 3.4.3

How to reproduce

  1. Add the custom filters /ad.htm^ and @@/sub.htm$document
  2. Create top.htm, sub.htm and ad.htm and launch static web server (see file contents below)
  3. Open top.htm (e.g. http://localhost:8080/top.htm)

Example file contents

top.htm

<iframe src="sub.htm" height="500"></iframe>

sub.htm

<strong>With srcdoc</strong>
<iframe srcdoc=""></iframe>

<strong>Without srcdoc</strong>
<iframe></iframe>

<script>
let iframes = document.querySelectorAll("iframe");
for (let iframe of iframes) {
  iframe.contentDocument.write(`
    <iframe src="ad.htm"></iframe>
  `);
}
</script>

ad.htm

ADVERTISEMENT

Observed behavior

  • Frame under heading "With srcdoc" failed to load
  • Frame under heading "Without srcdoc" loads successfully
  • Request to ad.htm is shown in DevTools as being blocked by filter /ad.htm^

Expected behavior

  • Both frames load successefully
  • Request to ad.htm is not shown in DevTools as being blocked

What to change

When encountering a request for which ext.getFrame() returns undefined but which specifies both a frameId and parentFrameId property, create a new about:blank frame for the one the request originates from and add it to the frame hierarchy.

For example, this could be achieved by extending ext.getFrame().

Further information

Chrome doesn't notify us of the anonymous frame with the srcdoc attribute. Therefore the extension doesn't know which frame the ad.htm request originated from. Due to that the exception rule is not applied and the request gets blocked.

Change History (9)

comment:1 Changed 9 months ago by greiner

One more thing to add is that I'm not quite sure why the browser doesn't notify us of certain anonymous frames. My best bet would be the usage of document.open("text/html", "replace") which results in no history entry being created, possibly in combination with other similar bad practices by any of the code involved in serving/rendering the ad.

comment:2 Changed 9 months ago by kzar

  • Cc sebastian added

Would you mind adding some explanation to the issue description of what this example page is doing and how come we don't handle it well so far?

Also, could you explain a bit more what your proposed change involves? From your example results it seems like you're creating frame Objects for the frame's parent frame ID as well?

Is this an issue in Firefox and Edge?

comment:3 Changed 9 months ago by greiner

  • Description modified (diff)

Would you mind adding some explanation to the issue description of what this example page is doing and how come we don't handle it well so far?

I added a bit more context regarding the example page but it is not clear yet what causes the issue so there's not much I was able to add there. Considering that this is a fallback solution for any situation for which the browser doesn't notify us of a frame being created, I considered it not being necessary to find out what exactly causes it since that would be merely an optimization that could be worked on separately (i.e. the more frames we can detect early on outside of the critical path, the fewer cases there are for which we need to fall back on adding frames while on the critical path).

However, I can understand if you disagree with this assessment.

Also, could you explain a bit more what your proposed change involves? From your example results it seems like you're creating frame Objects for the frame's parent frame ID as well?

My suggested approach is only creating a frame object for the frame the request originated from, not for its parent since we don't know what its parent's parentId is. I've tried to clarify that bit now in the description.

I assume your concern is that this approach cannot deal with a situation where a request is coming from an unknown frame whose parent is also unknown. I'd consider that to be a valid argument, I just don't know how we could handle such cases considering that all we know of the parent frame is its ID.

Is this an issue in Firefox and Edge?

I haven't tested it on Edge but it also affects Firefox.

comment:4 Changed 9 months ago by kzar

I haven't tested it on Edge but it also affects Firefox.

Which version of Firefox did you test with?

comment:5 Changed 9 months ago by greiner

  • Platform changed from Unknown / Cross platform to Chrome

I have now tried again to reproduce it on Firefox but was unable to so I updated the description to reflect that.

comment:6 Changed 9 months ago by kzar

  • Description modified (diff)

comment:7 Changed 9 months ago by kzar

I failed to reproduce this last night on Chrome 72, but apparently the site's behaviour has changed a bit. Some tips about reproducing the bug from Thomas in IRC:

I noticed that the error pattern also changed so essentially, if you
see anything blocked or hidden after the pxext.gif got blocked,
something's wrong (or if you never see an ad after a dozen or so
reloads)

comment:8 Changed 9 months ago by greiner

  • Description modified (diff)
  • Sensitive unset

I've invested a few hours into finding out exactly under what circumstances Chrome doesn't notify us of a frame. I found the culprit, created a minimal example and replaced the reproduction steps in the description with it.

comment:9 Changed 9 months ago by greiner

  • Description modified (diff)
Note: See TracTickets for help on using tickets.