"Access is denied" with iframes in IE

[tmsns]

In IE, when iframes are being added to the page, the GOPN function throws with"Access is denied".

Screenshot

How to reproduce

1. Go to https://jsbin.com/pafazegato/edit?html,output
   (I used a reference do a dummy doubleclick host, as my issue occurs when tags are being added to the page)
2. Open up the preview in IE, and open up dev tools
3. Make sure to refresh the page to see the "Access is denied" errors

Remarks

• I suspect that this only happens when opening up the dev tools. As getOwnPropertyNames is being used by the dev tools themselves.
• I'll send a PR later on today where I wrap the GOPN function (get-own-property-symbols.js#L125) with a try/catch.

[ljharb]

I'm a bit unclear on this; where is Object.getOwnPropertyNames() being called, that it throws?

[tmsns]

Well, to be honest, it's not 100% clear to me either.
As you can see, the code to reproduce the error is the polyfill and a simple iframe on the page. My theory is that the very fact of opening the devtools of IE, triggers the calls to Object.getOwnPropertyNames. When activating "breaking on uncaught errors", we can see that the object being passed is window, but more curiously the callstack only contains one frame, the call to it. I think the devtools calls Object.getOwnPropertyNames(window) to get data to be used in the devtools, not sure though.

[tmsns]

You can actually see that devtools is triggering the throwing Object.getOwnPropertyNames(window) by adding some DOM manipulation in the catch clause.

[ljharb]

Why would IE 11's devtools be calling a function that doesn't natively exist in IE 11?

[tmsns]

Object.getOwnPropertyNames exists natively on IE11, it's Object.getOwnPropertySymbols that doesn't exist, right? 🙈
This polyfill overrides the default implementation of Object.getOwnPropertyNames to filter away the properties that act as a Symbol. It uses the original function to do so. Appearantly, that custom usage throws.

[ljharb]

aha, interesting

[tmsns]

aha, interesting

Yeah, I found that interesting as well. :-) It does remind me on how other polyfills also impact how devtools is behaving (eg. webcomponents polyfill) Had not seen it before on these smaller polyfills though. 😃

Let me know if you need more info, or clarifications.

[ljharb]

We'll probably need a technique like in object-keys.

Easiest would be to depend directly on object-keys, but that would be best done in a major bump, since this package doesn't currently have deps, and it'd need a bit of restructuring to update it to modern approaches.

I'll look into possible solutions beyond just a try/catch.

[tmsns]

The highlighted technique is an exclusion list. What exclusions were you thinking of?

Also, when you talk about depending on object-keys, do you mean using it instead of relying on the built-in Object.getOwnPropertyNames? Or did you have something else in mind?

Some extra things I noticed:

• entering window or window.frames in the console throws as well (2x each)
• entering Object.getOwnPropertyNames(window) or Object.getOwnPropertyNames(window.frames) doesn't

It seems as if the objects passed directly by the devtools to the function have some kind of lowered security context. 🤔

[ljharb]

Yes, IE has some strange behaviors around this sort of thing.

We might even need something crazier where the gOPN wrapper temporarily restores the native function, calls it, and then reverts the native one back to the wrapper, so it can successfully call it.