s/upper-right/upper-left/

The "what do you see instead" section is perhaps a bit confusing.  It should probably read:

For layoutTreeNode's that describe nodes within an iframe, the bounding box corresponds to the position within the iframe rather than within the page.

Moved issue v8:7452 to now be issue chromium:816467.

Since the code mentioned is under inspector, I'm changing the component from Blink>DOM to Platform>DevTools.

zoe@, based on the changes to test expectations in your CL, do you know if this change was intentional?

if I remember correctly the goal behind the change was to give consistent results for pages that contain meta/CSS viewports.

For example look at the test-case I added: https://chromium.googlesource.com/chromium/src/+/8188223eeda59d008debc93a2b950bd6f7a931a9/third_party/WebKit/LayoutTests/inspector-protocol/resources/dom-snapshot-viewport.html

Before the change the text box's coordinates were not fully enclosed by the div's coordinates. It doesn't particularly matter how the coordinates are transformed, the issue was they were being transformed inconsistently.

It's possible I overlooked the iframe test expectation implications (so easy to do with golden data tests...), let me take a closer look at iframe behavior.

I've verified that the CL mentioned above changed the iframe behavior. Note that the inlineTextNodes had the "after" behavior even before my change.

My change was reconciling DOM positions with text positions, which is probably why I was OK with the golden data changes.

In other words my CL made things consistent, but didn't make them consistent in the way mmcduff expected, nor was I aware of DOM.getBoxModel.


I probably don't care either way, though I'd consider the current code more or less *working as intended*.

___


In the case where there's no weird transformations going on, converting back and forth between the two coordinate spaces should be fairly doable in client code.

However this becomes a little subtle if the iframe itself is transformed, such as by "transform: rotate(90deg)", or if the page has a viewport tag.

I'm not a layout expert and could be off-base but it seems like there are a few different reasonable approaches:

#1 The user may want to query the bounding box relative to containing document's layout
   (I think this is the way things are now)
#2 The user may want to query the bounding box relative to main document's layout
   (mmcduff wants this over the first way)
#3 The user may want to query the bounding box relative to the screen
   (e.g. viewport scale factor would have an effect, probably easy to compute given #2)

Where approach 1 and 2 are mutually exclusive (unless we export both of them, make which one to use an option, etc.)

mmcduff does this make sense? What is your use-case with respect to the above?

cc-ing a couple headless chromium people in case they have any thoughts.

My use case is related to automated analytics on web pages (i.e. what elements from what domains appear where in a document).  You are correct that I prefer approach #2.  My argument for approach #2 is that the DOMSnapshot.getSnapshot interface returns all DOM elements within a tab, and so I think it makes the most sense that all DOM.Rect's in the returned layout tree would use the same coordinate space.  If it were possible to call DOMSnapshot.getSnapshot on only a single frame within a tab, it would make more sense to base the coordinates on that frame's document.

Assigning to myself, unless someone else wants to take this.

Sorry for the lack of progress on this bug, been busy with other stuff.

In the meanwhile https://chromium-review.googlesource.com/c/chromium/src/+/1173717 added scroll offset information,

which should be useful in the common case where iframes aren't rotated.

Setting defect without priority to Pri-2.

Setting defect without priority to Pri-2.