[Webkit-unassigned] [Bug 174863] WebDriver: use in-view center point for clicks instead of bounding box center point

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=174863

--- Comment #5 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Brian Burg from comment #4)
> Comment on attachment 316448 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=316448&action=review
> 
> r- while we figure out the details of "in-view" and "obscured". For Mac/iOS,
> we need to make DOMRect.h a private header. I'll put up a revised patch that
> does that.
> 
> > Source/WebKit/UIProcess/Automation/Automation.json:429
> > +                { "name": "inViewCenterPoint", "$ref": "Point", "description": "The in-view center point for the requested element. Specified in page or viewport coordinates based on the useViewportCoordinates rameter." }
> 
> Nit: rameter -> parameter
> 
> I don't like this name, but 'interactableCenterPoint' isn't much better.
> However, this directly maps to the spec concept, so maybe it should just be
> left alone. :|

Yes, I simply used the spec name.

> My issue is that the name is inaccurate. For a <span> of text that line
> wraps, the entire element could be "in-view" and yet the center of the
> bounding box (i.e., the center point of part of an element that is inside
> the viewport-in this case) may not necessarily intersect one of the
> element's client rects.  So it's really inViewCenterPointOfFirstClientRect,
> or something.
> 
> > Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.cpp:523
> > +    WebCore::IntPoint inViewCenter;
> 
> This is missing the check of whether the element is "in view" at all.

I know, for now I just wanted to get a better click point, and I planned to do the in-view in a follow up. I thought we would that in a previous step, maybe using an js atom to do the check, so I assumed at this point we would know the element is in view for sure.

> According to the spec, if
> elementsFromPoint(inViewCenterPoint(elem.getClientRects()[0])) does not
> contain elem, then it is not considered in-view. There is some confusion of
> how to compute this since it seems kind of circular (the precondition of
> inViewCenterPoint(e) is that 'e' is in view).

elementsFromPoint? Do you mean id the center point is obscured?

> Alternatively, we could ignore this precondition and separately report in
> the command result whether
> - the element is "in view" per spec
> - the element is "obscured" per spec
> 
> Note: Element.elementsFromPoint just landed in TOT. So we could use it. :)

Ah, I'll check it.

> > Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.cpp:525
> > +    if (auto* clientRect = clientRectList->item(0)) {
> 
> Is it always the case that the first client rect is within the viewport?

I assumed that at this point scrollIntoView has always been called. Maybe we should only return the in view center point when scroll view parameter is true.

-- 
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/20170727/7ef90360/attachment.html>