1583159 - userScript's export() helper fails to export some common JS objects (Blobs, typed arrays, ...)

Status: RESOLVED WONTFIX

(WebExtensions :: General, defect, P3)

Description

[Rob Wu [:robwu]]

A user of the userScripts API reported that they wanted to transfer an object with a Blob and ArrayBuffer, but they were unable to do so: https://github.com/erosman/support/issues/96

Currently, only values that pass the following checks can be exported from an API script to a user script. In short, only primitive values, plain objects, functions, arrays, and objects with the page's principal can be exported at the moment.

Blobs, typed arrays and array buffers should also be safe to export. There are also other types that we should probably allow, to make script.export a bit more useful, including the value types listed at:
https://searchfox.org/mozilla-central/rev/e3fc8f8970491aef14d3212b2d052942f4d29818/js/xpconnect/wrappers/XrayWrapper.cpp#81-102

Because of these limitations, the script.export is not as useful as it could be, and extensions have to resort to using cloneInto as a work-around.

Comment 1

[erosman]

I found another bug in the same area.
I am trying to implement GM.info
All properties get through fine but the single hyphenated one 'run-at' doesn't

After some testing .... here is an example:

browser.userScripts.onBeforeScript.addListener(script => {

  const GM = {

    .....
    info: {name: 'FireMonkey', "run-at": 'document-idle', 'go_go': 'music'}
  }
});

in content script

console.log(GM.info);

result:
{
  "name": "FireMonkey",
  "go_go": "music",
  "run-at": undefined
}

I tested with other properties and ALL object properties with hyphen end up as undefined

Comment 2

[erosman]

Attachment: fm.zip

Minimal Sample for testing

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to erosman from comment #1)

I found another bug in the same area.
I am trying to implement GM.info
All properties get through fine but the single hyphenated one 'run-at' doesn't

Besides being an issue completely unrelated to the one described in comment 0, the hyphenated properties can actually be accessed by the userScripts code just fine (as a non-hyphenated property).

You can verify it yourself by changing a bit the test extension you attached (by access from the userScript code and logging the property value got, instead of logging the entire object and then resolve the getters from the "webconsole's interactive object representation", as your test extension is currently doing):

--- background.js       2019-09-25 16:18:34.000000000 +0200
+++ background-changed.js       2019-09-25 15:48:51.032252274 +0200
@@ -17,7 +17,7 @@
   // --- preppare script options
   const options = {

-    js: [{code: 'console.log("testing");console.log(GM.info);' }],
+    js: [{code: 'console.log("testing");console.log("DEBUG", GM.info["run-at"], GM.info);' }],
     matches: ['*://*/*'],
     runAt: 'document_idle'
   };

The above console log prints the expected value of "run-at" (as a proof that the userScript code is able to access the hyphenated property as expected).

The issue with the hyphenated getters that you noticed seems to only be happening for the devtools, it looks like an issue with the interactive devtools object representation, which seems to be able to successfully retrieve the values of the non-hyphenated getters but not from the hyphenated ones.

As mentioned earlier, the two issues does look unrelated, please file separate bugzilla issues for issues unrelated to each other.

Comment 4

[erosman]

The result is inconstant after getting through script.defineGlobals(). I tested a few times.

browser.userScripts.onBeforeScript.addListener(script => {

  const GM = {
    info: {name: 'FireMonkey', 'run-at': 'document-idle', 'one-two': 'music', 'three': 'art'}
  };
console.log(GM.info);
/* result
{
  "name": "FireMonkey",
  "run-at": "document-idle",
  "one-two": "music",
  "three": "art"
}*/

  script.defineGlobals({

    GM,
    GM_info:            GM.info
  });
});

From content script:

name: "FireMonkey"
"one-two": undefined
"run-at": "document-idle"
three: "art"

While it is showing the value for "run-at" correctly now, it doesn't show it for "one-two"
Yesterday both showed as undefined

I also tested console.log(GM.info["run-at"] === "document-idle"); from content script and I got true sometimes and false other times.

Whatever it is, it is inconstant and unreliable once it goes through script.defineGlobals()
ref: 71.0a1 (2019-09-25) (64-bit)

I understand that it may not strictly be under the topic's heading but it is still under the same method related to passing data to content script.

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to erosman from comment #4)

I understand that it may not strictly be under the topic's heading but it is still under the same method related to passing data to content script.

Bugzilla supports a "See Also" field to allow to mention other issues in the same area without making the conversation in a particular bugzilla issue harder to follow by mixing comments, STRs and test extensions related to different underlying problems.

Please do not add more comments about the "hyphenated properties" issue in this bug, we obviously wants to investigate and track it down too but not as part of this issue (as you may notice the 90% of the content in this bug is now unrelated to the issue originally reported).

File a new issue, link them together using the "See Also" field (if you can't set the "See Also" field for some lack of bugzilla privileges, CC me and Rob on the newly filed issue and we will take care of linking them together).

Thanks for your help and understanding.

Comment 6

[Luca Greco [:rpl] [:luca] [:lgreco]]

Comment on attachment 9095153 [details]
fm.zip

marking as obsoleted, the test extension has been attached to Bug 1584244.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Luca Greco [:rpl] [:luca] [:lgreco]]

The userScripts API this issue belongs to is the userScripts API namespace that was available only in Firefox manifest_version 2 extensions, that API namespace has been deprecated in manifest_version 3 extension where the same API namespace will be used for a different userScripts API shared with Chrome manifest_version 3 extensions (and also meant to be eventually supported by other vendors interested to support the use case that this API is meant to support).

Introducing support for the new MV3 API is tracked by Bug 1875475, but the part of the userScripts API this bug was related to is not part of what the new MV3 userScripts API namespace and so it does not fit into dependencies of Bug 1875475.

Given that this bug belongs to an API already on its deprecation path, I'm closing this as wontfix.