Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardize Firefox exportFunction() and cloneInto() #75

Open
minfrin opened this issue Sep 7, 2021 · 2 comments
Open

Standardize Firefox exportFunction() and cloneInto() #75

minfrin opened this issue Sep 7, 2021 · 2 comments
Labels
enhancement Enhancement or change to an existing feature

Comments

@minfrin
Copy link

minfrin commented Sep 7, 2021

Firefox offers two functions that enable functionality and/or objects present in a content script to be exposed in a controlled fashion to a webpage.

This mechanism keeps the security separation between the webpage and content script, while allowing webpages to access functionality defined in a web extension.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Sharing_objects_with_page_scripts#exportfunction

Standardise this (or a suitable variation) for all browsers.

@ghostwords
Copy link

Some context: #57 (comment)

@xeenon xeenon changed the title Standardise Firefox exportFunction() and cloneInto() Standardize Firefox exportFunction() and cloneInto() Sep 9, 2021
@xeenon xeenon added the enhancement Enhancement or change to an existing feature label Sep 9, 2021
@theseanl
Copy link

theseanl commented Sep 22, 2021

Documentations on exportFunction and cloneInto seems to be implying that these APIs are deeply integrated into Firefox's implementation details. That said, these APIs are definitely something that I'd love to see in other platforms, and having it well-documented would be great.

The current Firefox documentation on these APIs are quite a mess. Its documentations are very out-of-date, some of them are only available via google search cache. Existing documentations are based on providing examples, not on rigorous specification.

It is also based on very ad-hoc concepts; xray vision will see properties of DOM objects un-altered, but except for Object and Array. However, DOM objects are Object instances anyway, and this special casing leads to many weird behaviors involving prototypes.

It is a permission-based API, which means an innocuous-looking code can suddenly throw errors in runtime, in contrast to your friendly cross-origin errors, which are only thrown during only a few distinguished API calls. It seems that it is not possible to statically analyze a codebase for possibilities of such errors.

Therefore, the current status of this API is inherently developer-hostile. It 'works' for exposing simple callback functions to pages, but if you try to build anything marginally more complex, you will quickly fall into a maze of cryptic errors. I expect that there will be very few people who understands this API through the end. It even feels that Mozilla would want to phase out these APIs eventually.

Some deficiencies of the current API that I'd like to see addressed:

  • There is no way to unwaive Xray vision for an object. This was possible with Components.utils.unwaiveXrays in FF add-on SDK.
  • There is no reliable way to distinguish normal objects and xrayed objects, waived and unwaived.
  • There is no exportFunction counterpart for classes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Enhancement or change to an existing feature
Projects
None yet
Development

No branches or pull requests

4 participants