1593645 - Get correct offsets for nodes nested in iframes for BoxModelHighlighterRenderer

Status: RESOLVED DUPLICATE of bug 1593756

(DevTools :: Inspector, defect, P2)

Description

[Razvan Caliman [:rcaliman]]

The Fission-ready BoxModelHighlighter has two parts:

• an observer, BoxModelHighlighterObserver, which measures the target node for changes in size/position (this lives in the content process);
• a renderer, BoxModelHighlighterRenderer, which draws the highlighter on top of the inspected node (this lives in the parent process).

Before Fission, for nodes within iframes, it was possible to use Node.getBoxQuads() to measure a node's offsets against the top-level document using the relativeTo option. After Fission, we cannot pass references to documents from another process (ex: top-level document which contains the iframe)

In order for the renderer to position the highligther correctly, the offsets of a node from within the iframe need to account for the iframe's offsets in relation to the top-level document.

There are a few ideas to solve this:

a) somehow get a reference to the top-level document as a referenceTo in node.getBoxQuads() in auto-refresh.js (i.e. boundaryWindow should be the top-level document window)`

b) configure a custom option on the getBoxQuads() platform API so that it always returns offsets in relation to the top-level document (i.e.: no need to explicitly pass it as referenceTo)

c) recursively get iframe offsets in relation to their parent (if another iframe) or top-level document and account for these offsets when positioning the highlighter for a node in the renderer. This would likely be expensive, because the observer is running in a requestAnimationFrame() loop in order to react to any changes in node position from animations, transitions, resizes, etc.

Comment 1

[Razvan Caliman [:rcaliman]]

Attachment: test case with iframe

Document containing an iframe on another domain (glitch.me): https://bronze-baboon.glitch.me/
When working correctly, the Fission-ready BoxModelHiglighterRenderer should draw the highlighter correctly over the green <div> in the iframe.

Comment 2

[Brad Werth [:bradwerth]]

Razvan, what do I need to do to reproduce the problem? When I load the testcase, the highlighter is drawn correctly on the green box div in the iframe.

Comment 3

[Razvan Caliman [:rcaliman]]

(In reply to Brad Werth [:bradwerth] from comment #2)

Razvan, what do I need to do to reproduce the problem? When I load the testcase, the highlighter is drawn correctly on the green box div in the iframe.

Sorry about the confusion! The test-case doesn't highlight a problem yet because the highlighter can't yet reach content within remote frames. This is part of the Fission work.

But the test case serves as a starting point. There are two Node.getBoxQuads() calls: one for iframe from the top-level document and one for the node from within the iframe. The second call, the one for the <div> within the iframe, needs to return adjusted coordinates which take into account the offset of the iframe itself.

From conversations on https://bugzilla.mozilla.org/show_bug.cgi?id=1593756#c4, it seems we can't change the default behavior. So the second call should include the custom flag to return the adjusted quads.

Essentially, once given a flag (either custom or by specifying the top-level document's BrowsingContextID), the call to Node.getBoxQuads() from within the iframe should return offsets increased by 100 (the top and left margin of the iframe):

DOMQuad {
​​p1: DOMPoint { x: 200, y: 200, z: 0, … }
p2: DOMPoint { x: 300, y: 200, z: 0, … }
p3: DOMPoint { x: 300, y: 300, z: 0, … }
p4: DOMPoint { x: 200, y: 300, z: 0, … }
​​}

Comment 4

[Chris Peterson [:cpeterson]]

Tracking Fission DevTools bugs for Fission Nightly (M6)

Comment 5

[Razvan Caliman [:rcaliman]]

Solved by Bug 1593756