React: Safari Devtools flooded with security errors on react-dom selection work with iframes with diff origins

Created on 27 Oct 2018 · 7Comments · Source: facebook/react

hey folks, looks like this code added small issue with safari and it could flood devtools console output with messages like this:
screenshot 2018-10-26 at 15 25 33
As I understand it happens here and I see you catch the error, but safari still adds the error message if you have iframes with different origin

Safari DOM Bug

Source

asci

👍7

Most helpful comment

Here is a working version of @asci version too: https://codesandbox.io/s/ojrq78r87q

This is the last thing holding us back from upgrading Framer to 16.8 cc @gaearon

Also, hi @jashkenas, always nice to run into you, even if it's a bug :-)

koenbok on 27 Jan 2019

👍3 👀1

All 7 comments

@asci Thanks for reporting this issue. Do you have the time to create a reproduction case for us so we can look for potential solutions?

philipp-spiess on 29 Oct 2018

👍2

@philipp-spiess here it is https://gist.github.com/asci/5f1afb9a772392adf318c624deac9a7a
to reproduce the issue you need to serve there files from different locations and then click on textarea and check console output

one of potential solutions:
to check iframe src origin before accessing contentDocument

while (element instanceof win.HTMLIFrameElement && element.src.indexOf(location.origin) === 0) {

If it's good we can create PR

asci on 29 Oct 2018

hello! any ideas\updates on this?

asci on 27 Nov 2018

I was just about to write up a different issue for this — but instead, I'll just pile on to this one. Here it is, pasted over:

Do you want to request a feature or report a bug?

A bug, I'm sorry to say. (But it's not exactly your bug ... as will soon become apparent.)

What is the current behavior?

To the best of my understanding, during DOM updates, ReactDOM looks at document.activeElement to try and determine the element that currently has focus on the page. Unfortunately, in new versions of Safari, calling document.activeElement, when the active element belongs to an iframe with a different origin than the parent page, appears to throw an uncatchable error:

Here is a minimal reproduction in a JSFiddle: https://jsfiddle.net/Luktwrdm/1484/

In Safari, open your console, then click on the "Click to play" button (which will call setState() periodically), and then click into the embedded iframe.

You'll see the setState calls triggering the error above.

But it's really Safari's bug, not yours. If you then switch into JSFiddle's results frame, with text in the iframe selected, any attempt at reading document.activeElement will trigger the error ... and also return the frame:

And the error cannot be caught (getActiveElement is already doing this):

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

Safari 12 and React 16 trigger this error. I'm not certain about previous versions of React or Safari.

Suggested fix?

Ideally, Safari would quickly release a new version that fixes this error for activeElement. But if that doesn't happen — I'm not sure if there's any way to safely use document.activeElement in Safari currently.

jashkenas on 17 Dec 2018

👍3

Here is a working version of @asci version too: https://codesandbox.io/s/ojrq78r87q

This is the last thing holding us back from upgrading Framer to 16.8 cc @gaearon

Also, hi @jashkenas, always nice to run into you, even if it's a bug :-)

koenbok on 27 Jan 2019

👍3 👀1

@asci

to check iframe src origin before accessing contentDocument
while (element instanceof win.HTMLIFrameElement && element.src.indexOf(location.origin) === 0) {
If it's good we can create PR

I'm not sure. It is possible to create (and use) iframes that have no src property, e.g. via:

const frame = document.createElement('iframe');
const frameDocument = frame.contentDocument;
frameDocument.open();
frameDocument.write(html);
frameDocument.close();

Or even via absurd things like this one:

const frame = document.createElement('iframe');
frame.src = "javascript:<html><body>Hi!</body></html>";

And of course Object URLs and I don't know what else. We'd probably need a much more robust check to find out if the frame is cross domain.

All of that said, this is only about an error in the dev console, right? The execution is not limited since it will still throw an error (besides logging the annoying error in the console) which would allow our fallback logic to run and function correctly.

philipp-spiess on 13 Mar 2019

Fix should be out in 16.8.6.