1414602 - URLSearchParams.keys() and other iterators don't work through X-ray wrappers

Status: RESOLVED DUPLICATE of bug 1023984

(Core :: XPConnect, defect, P2)

Description

[nick.gelinas]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171024165158

Steps to reproduce:

Run the following in the the content_script of any web extension.

```javascript
const url_string = "https://accounts.google.com/Logout?hl=en&continue=https://www.google.ca/search%3Fnum%3D50%26source%3Dhp%26ei%3DCSb-WcnyJYXVjwT9wZTgCQ%26q%3Dfirefox%2Bevent%2Bpages%26oq%3D%26gs_l%3Dpsy-ab.3.0.35i39k1l6.0.0.0.3611.2.1.0.0.0.0.0.0..1.0....0...1..64.psy-ab..1.1.145.6...146.1TCP4wGaj5s&timeStmp=1509852638&secTok=.AG5fkS8WiJXwXfh5Ti4C2DpHpG3yAF9lgQ";

const url = new URL(url_string);
const params = url.searchParams;
const keys = params.keys();
for (let key of keys) {
    console.debug(key);
}
```


Actual results:

TypeError: keys is not iterable


Expected results:

All query parameter keys should be logged to the console.  This is what happens when running the code directly in the console from any page.  This only seems to fail in content scripts.  This works as expected in background scripts.

There is no mention of this exception in the content script documentation[0] nor the URLSearchParams.keys docs[1].  Though it's written as 'Experimental', it has been in the supported in the browser since version 44.  Is it intended to work as documented?

[0]: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts
[1]: https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/keys

Comment 1

[Andy McKay]

There's nothing about searchParams that should break in content scripts since it is basically string parsing. The following works just fine for me in a content script:

  let url = new URL('http://example.org/?a=b&b=c');
  for (let entry of url.searchParams) { 
    console.log(entry); 
  }

If you have concerns about how searchParams and keys work, we'll bounce this bug over to Firefox since I don't think its a WebExtensions bug.

Comment 2

[nick.gelinas]

The code you tested doss indeed work in content scripts.  It is not however the same as the code I provided nor the code example in URLSearchParams#keys documentation.  That still fails for me (v56 on Ubuntu)

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/74ad9ec5b010
fix flake8 lint errors. r=bustage-fix

Comment 4

[Masatoshi Kimura [:emk]]

(In reply to Pulsebot from comment #3)
> Pushed by [e-mail]:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/74ad9ec5b010
> fix flake8 lint errors. r=bustage-fix

Sorry, I wrote a wrong bug number. Bug 1414060 is the correct one.

Comment 5

[Masatoshi Kimura [:emk]]

This is indeed a bug, and maybe related with bug 1414674 because browser console had the following error:
XrayWrapper denied access to property Symbol.iterator (reason: value is callable). See https://developer.mozilla.org/en-US/docs/Xray_vision for more information. Note that only the first denied property access from a given global object will be reported.  content.js:2:20
TypeError: url.searchParams.keys(...) is not iterable

Comment 6

[Tom S [:evilpie]]

So I think there are two different issues here: Just using for (let x of keys) {}, seems to window.keys, which is a function. For the real Xray case we need to do bug 1023984.

Comment 7

[Kris Maglione [:kmag]]

I think that for WebIDL objects, a better solution may be to create the iterator in the caller compartment. Accessing iterators through X-rays would be pretty expensive. If we can keep most of the intermediate objects in the caller compartment and only generate wrappers for the values, the result should be much faster.

Not sure how much work that would be, though. I'll look into it.

Comment 8

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/74ad9ec5b010

Comment 9

[Andrew Overholt [:overholt]]

(P2 as a "maybe we want to do this soon" but happy to move up or down priority-wise when Kris gets back after comment 7)

Comment 11

[Geoffrey De Belie (Smile4ever)]

This is still an issue in Firefox 96.