[Webkit-unassigned] [Bug 213139] New: Automation.computeElementLayout should return iframe-relative element rects (when coordinate system is 'Page')
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Jun 12 10:44:29 PDT 2020
https://bugs.webkit.org/show_bug.cgi?id=213139
Bug ID: 213139
Summary: Automation.computeElementLayout should return
iframe-relative element rects (when coordinate system
is 'Page')
Product: WebKit
Version: WebKit Local Build
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: WebDriver
Assignee: webkit-unassigned at lists.webkit.org
Reporter: bburg at apple.com
CC: bburg at apple.com
Currently it's relative to top-level browsing context, which does not match the non-normative note (https://w3c.github.io/webdriver/#get-element-rect):
"""
The Get Element Rect command returns the dimensions and coordinates of the given web element. The returned value is a dictionary with the following members:
x
X axis position of the top-left corner of the web element relative to the current browsing context’s document element in CSS pixels.
y
Y axis position of the top-left corner of the web element relative to the current browsing context’s document element in CSS pixels.
"""
However the remote end says to "let coordinates be the result of the 'calculate the absolute position' algorithm, which does not seem to align with the note in the case where the main frame is scrolled:
"""
To calculate the absolute position of element:
1. Let rect be the value returned by calling getBoundingClientRect.
2. Let window be the associated window of current top-level browsing context.
3. Let x be (scrollX of window + rect’s x coordinate).
4. Let y be (scrollY of window + rect’s y coordinate).
5. Return a pair of (x, y).
"""
It seems to me that adding the scrollX of the top window is unnecessary to achieve the desired result.
In any case other browsers return iframe-relative coordinates from Get Element Rect.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200612/8f73d662/attachment.htm>
More information about the webkit-unassigned
mailing list