You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in firefox, a moz-extension iframe in a web page only has content script level APIs, and as such receives only messages intended for content scripts, not for extension pages
This means it is hard (impossible without ports?) to broadcast messages to everywhere in an extension without duplicates.
Workarounds that feel good at first, but have gotchas
Different options you might consider are:
Idea 1: Use chrome.runtime.sendMessage only
Problem: Iframes containing moz-extension:// pages will not receive the message
Idea 2: Use chrome.tabs.sendMessage only
Problem: Listeners in the background page will not receive the message
Idea 3: Use chrome.runtime.sendMessage and chrome.tabs.sendMessage
Problem: In Chrome, extension pages open in a tab of their own will receive duplicates
Idea 4: Use only chrome.runtime.sendMessage in Chrome and both in Firefox.
Problem: Normal content scripts will not receive the message in Chrome
Idea 5: Opening a port to the background from everywhere that wants to get broadcasts.
Problem: Introduces the requirement to track open ports in the background
Conclusion
With all of this considered, it feels like the ideal solution would be tweaking the behaviour of these so they are consistent. This would ideally be done in a way that supports the broadcast use case - not all behaviours meet this criteria. The other option would be introducing a new API that reliably broadcasts to absolutely everywhere that's listening.
The text was updated successfully, but these errors were encountered:
Idea 6: make Firefox implement extension:// iframes properly. AFAICT, their current behavior was caused by single-process architecture at the time they implemented WebExtensions. Now that Firefox is fully multi-process they can run the iframe in a different process that belongs to the extension as it should and as it does in Chrome. This is tracked in https://bugzil.la/1443253
I summarised everything in a table to help (at the very least) future me. I've also added a column for Safari where opening a port seems to be the only way to message an extension page within an iframe - would love to see a behaviour change in that scenario @xeenon ❤️
One place where standardisation of behaviour would be especially helpful is when trying to broadcast messages to all scripts in an extension.
Existing Behaviour
To understand the problem, first it helps to understand the behaviour across browsers:
Chrome
Messages sent using chrome.runtime.sendMessage do reach chrome-extension:// pages in an iframe.
From @dotproto in the Chromium Slack:
Firefox
Messages sent using chrome.runtime.sendMessage do not reach moz-extension:// pages in an iframe.
From @zombie in the Mozilla matrix:
This means it is hard (impossible without ports?) to broadcast messages to everywhere in an extension without duplicates.
Workarounds that feel good at first, but have gotchas
Different options you might consider are:
Idea 1: Use chrome.runtime.sendMessage only
Problem: Iframes containing moz-extension:// pages will not receive the message
Idea 2: Use chrome.tabs.sendMessage only
Problem: Listeners in the background page will not receive the message
Idea 3: Use chrome.runtime.sendMessage and chrome.tabs.sendMessage
Problem: In Chrome, extension pages open in a tab of their own will receive duplicates
Idea 4: Use only chrome.runtime.sendMessage in Chrome and both in Firefox.
Problem: Normal content scripts will not receive the message in Chrome
Idea 5: Opening a port to the background from everywhere that wants to get broadcasts.
Problem: Introduces the requirement to track open ports in the background
Conclusion
With all of this considered, it feels like the ideal solution would be tweaking the behaviour of these so they are consistent. This would ideally be done in a way that supports the broadcast use case - not all behaviours meet this criteria. The other option would be introducing a new API that reliably broadcasts to absolutely everywhere that's listening.
The text was updated successfully, but these errors were encountered: