The _exception_ doesn't repro for me on Linux but something does happen. As far as I can tell, the gcast available API callback is causing something to change. On linux, I see "GoogleCast Loaded" after 5-7 iterations at which point console logging changes in a weird way. Presumably you would also see it on Mac if the exception didn't occur.

To repro this open

https://codepen.io/anon/pen/rvpXdm

and then open the devtools console. What you see is that the console logging output is different when castAvailable becomes true. See the attached screenshot. This means that something has changed. On Mac the change triggers an exception, on Linux it interferes with console.log.

Passing this to the cast folks and bumping the priority since it seems like some fundamentals break when the API is used.

BTW, the summary of this bug seems wrong, getElementById is only called once. It's either the node returned by createElement or by createTextNode that is invalid as an argument to appendChild.

Deleted: gcast-logging.png 235 KB

	gcast-logging.png 235 KB View Download

olivierrobin@ could you PTAL?
ccing miu@ since he seems to be working on Cast

The tag is iOS but the text is mac and linux.
mfoltz@, is it mac or iOS?

It was reported originally on iOS.

Sorry, ignore the references to Mac, that was an error on my part (although I assume Mac would show the same behaviour as linux - no exception but weird output in the dev tools).

The issue is that codepen uses cross origin iFrames.
Code frame is https://s.codepen.io when window is https://codepen.io.

When the codepen tries to initialize cast, it calls invokeOnHost, and the first instruction is 
if (typeof window.top.__gCrWeb.windowId != 'string') {

which tries to do a cross origin call and throws the exception.

Does this bug represent a problem not seen on codepen.io? It looks like codepen can't be used on iOS due to cross origin iframe restrictions.

If I use the source from the codepen in comment #0 and put it into an html file (attached), it looks like this functions correctly on iOS.

Deleted: codepen_result.html 1.2 KB

codepen_result.html 1.2 KB View Download

The problem is seen with codepen.
If you load the page in 0, you get an error in the web inspector.

It looks like the problem is not with codepen. Below is another example which reproduces the bug on Chrome for iOS both on iPad and iPhone

The reason this didn't reproduce for you when taken off codepen is because for some reason now the google cast lib seems to finishing initialization before the window.onload event.

If it indeed finishes before we have any reference to a DOM node then everything's fine. If it finishes after then any previously referenced DOM node becomes invalid.

Please find attached better script illustrating the problem.

In the that script I'm getting a ref to the 'content' node on DOMContentLoaded, before the GCast is initialized, and then I'm checking the node's status within an interval.

A little after __onGCastApiAvailable is invoked the 'content' node becomes invalid.

Deleted: example.html 653 bytes

example.html 653 bytes View Download

Any updates here?

Mike, let's try to fix this in M68. 

syatam@, thank you for the example script in comment #9. I tested this in the iOS simulator so that I could easily inspect the JS and I am able to reproduce the node becoming invalid.

However, I am not confident that the |instanceof Node| test is actually correct. I inspected bodyNode at the testNodesStatus alert and at the GCast loaded alert and it doesn't actually look like |bodyNode| is becoming invalid. Although the instanceof test fails, |bodyNode| still looks OK to me. Please see the attached screenshots of the debugger at each of these points.

(I am also no longer seeing a SecurityError in the console.)

Deleted: cast_loaded.png 879 KB

	cast_loaded.png 879 KB View Download

Deleted: testNodeStatus.png 786 KB

	testNodeStatus.png 786 KB View Download

mfoltz@ or syatam@ are you still seeing this?

(Fix CC'd members)

This may be related to Bug 889529.  In both cases the code loaded by cast_sender.js seems to be causing problems with DOM APIs.  I'm not really set up to debug this at the moment, but CCing two members of the Cast team who may want to see the data in this bug.

I believe that this is no longer an issue, as Cast support has been removed from iOS (Bug 872050).