-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Content from iframes is still not fully supported #133
Comments
@mflorea How about checking for |
Using something like
super fast. I don't understand what's wrong with this. |
@mflorea The issue is that that will only let us distinguish between text nodes, comment nodes and regular elements. We even need to find things like HTMLTextAreaElement. Maybe, after all, the only option is to check for attributes if we are to support all the possible ways of using iframes. That also feels hackish. |
This seems relevant: https://groups.google.com/g/mozilla.dev.platform/c/bfwNKKiAxcw This is more than a decade old. They seem to suggest comparing things from the prototype. Some of the other methods, like |
If we don't want to access the prototype through |
It seems the fix from #126 is not enough to properly support iframes. The root problem is that the realm of the JavaScript interface (e.g. Text) of a DOM node is not always synchronized with the node's owner document. For instance, for a given DOM text node the following is not always true:
One such case when this is not true is when a DOM node is adopted. Adopting a DOM node changes its owner document, but it seems it doesn't change its prototype in all browsers. See https://jsfiddle.net/f7pbmue6/2/
Judging by https://bugzilla.mozilla.org/show_bug.cgi?id=1470017 my feeling is that Chrome's behavior is the standard one which means the prototype and the owner document doesn't have to be in sync. If that is the case then using
instanceof
for checking the type of a DOM node becomes very fragile, since the node's prototype can be from any realm (you can imagine having multiple iframes and adopting nodes between them). We would need a way to find the (original) realm in which the DOM node was created, but I'm not sure this is possible.The text was updated successfully, but these errors were encountered: