1415539 - content_script not loaded into about:blank iframes despite all_frames:true and match_about_blank:true in manifest.json

Status: UNCONFIRMED

(WebExtensions :: General, defect, P3)

Description

[philipmorant]

Attachment: console output

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171003101344

Steps to reproduce:

Note: this is similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1272890. However that bug is marked as fixed in version 52, and I am experiencing this problem in version 56.

I maintain Drag To Scroll (https://addons.mozilla.org/en-US/firefox/addon/drag_scroll/). manifest.json specifies all_frames:true, matches:<all_urls>, run_at:document_start and match_about_blank:true. Permissions: storage, contextMenus

Example page that shows the problem:
https://www.washingtonpost.com/news/politics/wp/2017/11/07/trump-just-made-a-bad-night-for-republicans-much-worse-for-himself/

Content scripts are loaded correctly into those twitter iframes which appear high in the page but are not loaded into tweet iframes which appear lower in the page and are reached only after scrolling. I thought at first that these iframes were different because they were being loaded dynamically, but devtools seems to show that the js relating to the tweets is loaded during initial page load. Are they loaded from a scroll event handler ? The page has several such event handlers but they're all from washingtonpost.com, not twitter.

Inspecting network activity in devtools, I see that twitter gets js from cdn.syndication.twimg.com/tweets.json?callback=...
which calls previously loaded js function cb0(). I have tried to find the code for cb0() but was unable.
I have confirmed that the problem iframes are not present in the original HTML GET.

More details:

the problem iframes are not sandboxed as far as i can see (no sandbox attribute in <iframe>), although some elements have sandboxroot class.

frame info reports address about:blank, quirks mode, text/html

The problem occurs regardless of whether the addon was installed via AMO or via about:debugging Load Temporary Addon.

console.log() from the content_scripts demonstrates that the content_scripts are correctly loaded for the top level frame and for 2 further frames: twitter_cookies.html and widgets/follow_button, in other words not for the tweet iframes.

The content scripts specify use strict;

console shows various problems, none of which look relevant to me. Attached as wapo.console.

Comment 1

[philipmorant]

Further testing shows that a trivial addon (console.log only) appears to work correctly.

Please keep this open while I investigate further.  It could still be a bug.

Comment 2

[philipmorant]

The problem may be caused by interference from an adblocker addon. I will raise the issue with them and close this bug.

Comment 3

[philipmorant]

Attachment: xpi which shows the issue

Steps to reproduce:
create new blank profile
set xpinstall.signatures.required to false
Load https://www.washingtonpost.com/news/politics/wp/2017/11/07/trump-just-made-a-bad-night-for-republicans-much-worse-for-himself/?utm_term=.85ec652db5a4
Open browser console
Open xpi file trivial.xpi & click Ok to install
Observe a console line  beginning trivial.contents.js loaded in about:blank
It also shows tweet content: Ed Gillespie worked hard but did not embrace me ...

Now clear the console and press F5.  Ffox does not load the content script into the twitter frame this time.

Note that I experienced slight variation in producing the tweet on the console when installing the xpi for the very first time in a profile. However, there was no variation when re-installing the xpi in the presence of the washington post page. That ALWAYS produced the console tweet output.

Comment 4

[Kris Maglione [:kmag]]

This works as expected for me. However, it's worth noting that document.body is likely to be null at this point, which means your script will throw rather than logging anything other than an error to the console.

Comment 5

[philipmorant]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #4)
> This works as expected for me. However, it's worth noting that document.body
> is likely to be null at this point, which means your script will throw
> rather than logging anything other than an error to the console.

I've altered the xpi, setting run_at:document_idle and making it more defensive & patient (setInterval()).

log output is basically the same story. It is reporting an about:blank iframe which could conceivably be a twitter iframe - I can't prove otherwise, at any rate - but there's no textcontent, and getElementById() can't find a certain div which is known to be present in the html. addEventListener(mousedown) is not logging anything when I mousedown on the twitter frames.

Is it possible that the content script did load, but is somehow blinded (permissions, sandbox, or maybe twitter is doing something funny and instantiating its own window and document) ?

I assume that you're running a debugger or at least have much better access than I do, and that you have a high degree of confidence that it is indeed loading.

Comment 6

[philipmorant]

Attachment: defensive.and.patient.xpi

Comment 7

[u603568]

> It is reporting an about:blank iframe which could conceivably be a twitter iframe

It's not a twitter.com iframe. The iframe's document.domain property is "www.washingtonpost.com", and the iframe's window.origin is "https://www.washingtonpost.com". So mainly the page creates an empty frame, and fills it manually.

Comment 8

[philipmorant]

(In reply to [e-mail] from comment #7)

> So mainly the page creates an empty frame, and fills it manually.

I'm not sure exactly if we're both talking about the same iframe - but it probably doesn't matter.

Anyhow, I have a bit more clarity on this issue:

If I add 
<iframe src='about:blank'></iframe>
to a test page then it suffers the same problem as the problem twitter iframes.
So it appears to be simply that firefox 56 and 57beta are not loading content scripts for about:blank iframes, despite all_frames:true and match_about_blank:true.
There's no issue with cross-origin iframes.

The twitter iframes referenced in my original description are about:blank iframes, same origin as window.top, which dynamically loaded twitter <script> tags are filling post document load. Twitter is inconsistent about when it loads up. Sometimes there's no loading until you've scrolled the iframe into view; other times the very same iframe loads within a few seconds of DOM load and before the iframe has been scrolled into view.

window.frames[x].addEventListener('mousedown', () => {console.log(...)}) works (ie reports events) on these about:blank iframes.  This proves at least that firefox is aware of the iframe's existence.

Comment 9

[philipmorant]

Attachment: manifest.json

The manifest.json associated with this issue.
NB. run_at:document_idle as opposed to run_at:document_start makes no difference to this issue.

Comment 10

[Simon Lydell]

I've run into this bug as well.

Here's a minimal reproduction, containing a minimal extension and a minimal test page: https://github.com/lydell/about-blank-webext

Here's my analysis:

If an iframe is inserted some time after page load
and it has no src attribute
content scripts won't run in it.

Comment 11

[pa.trickjlp]

this is also an issue for ember inspector https://addons.mozilla.org/de/firefox/addon/ember-inspector/ .

it should inject into the iframe at https://ember-twiddle.com/, but doesnt. it works on chrome