HTML Elements sometimes get a class from an iframe's realm
Reported by
hay...@luckyorange.com,
Dec 6
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36 Steps to reproduce the problem: 1. Open parent.html in browser (will need to run a simple http server so iframe code can go cross-origin) 2. Check console after 2 seconds, should throw error of "No good". 3. Commenting out the noted line in frame.js should fix. What is the expected behavior? I would expect that the referenced DOM element would always retain the prototype scoped to the window it was created in rather than the window it was referenced in. What went wrong? When innerHTML is used to add a DOM element to the top level window, a mutation observer running in a child window returns a reference to the added DOM element. When storing that reference on an object in the child window, the prototype for the DOM element switches to one created by the child window rather than the one created by the parent window. This causes "element instanceof HTMLElement" checks to fail on the top window. This only appears to happen when adding the element via setting innerHTML and with a mutation observer. Did this work before? No Does this work in other browsers? Yes Chrome version: 71.0.3578.80 Channel: stable OS Version: OS X 10.14.0 Flash Version:
,
Dec 7
Attaching a minimized single-file repro below. 1. open test.html Expected: "GOOD!" is shown Observed: "BAD!" is shown Bisected to an ancient r167707 "WebKit Roll 134347:134601" https://trac.webkit.org/log/webkit/?rev=134601&stop_rev=134347&limit=900 Probably useless now but FWIW suspecting https://trac.webkit.org/changeset/134350/webkit/ "Make Frames and HTMLFrameOwnerElement less friendly"
,
Dec 10
Able to reproduce the issue on chrome reported version# 71.0.3538.80 and on latest chrome# 73.0.3635.0 with sample file provided in comment# 2 using Mac 10.12.6, Windows-10 and Linux 17.10. As this issue is seen from M-60(60.0.3112.0), hence considering this issue as Non-Regression and marking it as Untriaged. Thanks!
,
Jan 10
A couple of notes. The element becomes an instance of the iframe's HTMLDevElement, you can test this with by adding id="iframe" and then test instanceof iframe.contentWindow.HTMLElement ? 'GOOD!' : 'BAD!'; Another interesting point is that if anything in the parent frame looks at the test element's type e.g. just adding typeof test; the to prototype is set to the parent's HTMLDivElement. So the mutation observer is not changing the prototype, it seems like the first piece of code to look at it lazily sets it and if the observer is first, it get s prototype from the iframe's realm.
,
Jan 11
,
Jan 11
Using bisect-builds.py I find that 338780 had this behaviour and 338771 crashes on that test.html. So this is a long-standing bug.
,
Jan 11
Shiino-san, could you take a look at this. It seems like this is P2 since it's been around for so long bug but mixing up realms is quite worrying and maybe there is something more serious possible.
,
Jan 11
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by gov...@chromium.org
, Dec 7