Jacob Barkdull Reporter
	Description • 6 years ago

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

1. Create a content script that creates an iframe on any website.
2. Create a page that contains an iframe that loads an external website, and load this page with a moz-extension:// URI in the iframe created by the content script.
3. Create another content script which gets added to all frames on the page, and in this script listen for page load events.


Actual results:

The page load events are not detected by the content script created at step 3 when it is attached to the external page loaded in the iframe created at step 2.

This error is thrown in the Browser Console:

    "Error: Could not establish connection. Receiving end does not exist."


Expected results:

All content scripts no matter how many iframes deep the page they are attached to are nested should be able to detect page load events.

This problem is specific to Firefox, and does not occur in Chrome. I have attached an example extension that demonstrates the issue. There are two directories included in the attached ZIP file, one is the extension for Firefox and the other is the same extension for Chrome.

	Jacob Barkdull Reporter
	Comment 1 • 6 years ago

I forgot to mention: In the example extension attached, the page loaded in the iframe works when viewed by itself. You can test this yourself by doing a simple Context Menu -> This Frame -> Open Frame in New Tab. This should prove that the iframe is somehow the cause of the issue.

	Gingerbread Man
	Comment 2 • 6 years ago

Duplicate of bug 1214373?

	Jacob Barkdull Reporter
	Comment 3 • 6 years ago

(In reply to Gingerbread Man from comment #2)
> Duplicate of bug 1214373?

I do not believe this bug is a duplicate of 1214373, as that bug is about cross-origin access.

In this bug's case, the page in the iframe loads, and the content script gets attached to the page in the iframe. And yet, the load events aren't detected.

I do, however, believe this bug should count towards bug 1161828, since this bug is specific to Firefox.

	Jacob Barkdull Reporter
	Comment 4 • 6 years ago

I have determined that iframe nesting has nothing to due with the bug. This new version of the example extension contains two versions of the extension, one where an iframe is nested within another iframe, and one where two iframes are added to the page separately. Both versions exhibit the same bug.

I have also determined that the load events do fire, but that the messages sent using `browser.runtime.sendMessage` are not received by the other frame listening for them. These messages can be received by a background page script. I could receive the messages in the background page script and send them again, but sending messages from the background page script to the frame script doesn't work either.

	Jonathan Watt [:jwatt]
	Comment 5 • 6 years ago

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

	Kris Maglione [:kmag]
	Comment 6 • 6 years ago

browser.runtime.sendMessage does not send messages to content scripts. If you want to send a message to a content script, you need to use browser.tabs.sendMessage.

	Jacob Barkdull Reporter
	Comment 7 • 6 years ago

(In reply to Kris Maglione [:kmag] from comment #6)
> browser.runtime.sendMessage does not send messages to content scripts. If
> you want to send a message to a content script, you need to use
> browser.tabs.sendMessage.

This bug has nothing to do with content scripts.

The iframe happens to be created using a content script, but the extension makes no attempt to send messages to that content script. This bug is about the page that is loaded in the iframe, which is an extension file (moz-extension://), and as such should be able to send and receive messages using browser.runtime.sendMessage and browser.runtime.onMessage respectively.

However, this doesn't work because the iframe is wrongly given content script scoping and privileges. For this reason, I would accept this bug being marked as a duplicate of bug 1443253, but it is not invalid.

And again, this bug does not occur in Chrome. If we are actually trying for compatibility with Chrome, than this bug needs to be fixed.