elementFromPoint + elementsFromPoint

[sjorsdonkers]

Depends on: #638

Implements the last 2 web apis for Playwright click:

• Document.elementFromPoint
• Document.elementsFromPoint
  https://developer.mozilla.org/en-US/docs/Web/API/Document/elementFromPoint

Reimplemented:

• Node.getRootNode also in netsurf
• Element.getBoundingClientRect
• Element.getClientRects

[karlseguin]

I think this is a problem. Why does it return null? I mean, I know why it returns null, but I don't think it should.

This is the HTML document:

 <div id="content">
  <a id="link" href="foo" class="ok">OK</a>
  <p id="para-empty" class="ok empty">
    <span id="para-empty-child"></span>
  </p>
  <p id="para"> And</p>
  <!--comment-->
</div>

shouldn't there be something at 0.5, 0.5?

[sjorsdonkers]

Our renderer is lazy so only renders things that have been registered.
The user cannot really know what the location is of any element without having queried for its location.

I think that returning document.documentElement is better.
Not sure if we want to (re-)register all elements when we call getElementAtPosition. The only use case I can currently see is when the script relies on the renderer being filled in a deterministic way, which I think they should not.

[sjorsdonkers]

We will however likely need to make our rendered a bit less flat.
Meaning a bit of a tree where an element can hold a list of other documents.

[sjorsdonkers]

I think we should document very clearly how our renderer works and what is and what is not a valid use case scenario.
We need to avoid falling into a pit where we end up having to implement a full renderer.

I'll start a discussion to document the current design ideas and goals of the renderer, and how that changes what kind of script we support (like no guessing what is as 0.5 0.5).
The only alternative that I see that would be better is if we have an on-the-fly renderer. That only renders everything on demand for a function such as this, but still does not keep track of changes and such.
For now I think we should stick with the no guessing (and no overlaying approach until it breaks)

[sjorsdonkers]

This logic is here for now as I think it definitely should not be in the FlatRenderer.
We may wrap the FlatRenderer in a ViewPort kind of object which would handle these as well as multiple documents and document renderer relationships.
But I do not think this is the right time to go there.

[sjorsdonkers]

I believe that we should not be throwing these errors in this use case, so a pre-exiting bug that is not fixed in the PR

[karlseguin]

Can also do:

@intFromPtr(root) == @intFromPtr(state.document.?)

but I'm not sure one is that much better than the other.

[sjorsdonkers]

Ye, I choose not to as making it a habit means every time that code is copied one would need to make sure the pointers of comparable types. Now if there is a function netsurf.zig that does the conversion it should be safe. But also meh :) I left it as it was.

[karlseguin]

Just trying to understand.

If @intFromPtr(self) == @intFromPtr(state.document.?), you could use the existing parser.nodeOwnerDocument ?

But for cases where the document isn't attached, and possibly also the shadow dom, you use the new nodeGetRootNode (which is also safe to use if it is attached, just not as efficient).

Is that right?

[sjorsdonkers]

1. if self == state.document than we can return self [htmldocument ]
2. if self == state.document.documentElement than we can return state.document [htmldocument ]
   In those cases that would also be the same as parser.nodeOwnerDocument

Note that nodeOwnerDocument is set even for detached nodes. It references the original document until it is appended as child to another document.
So we cannot use nodeOwnerDocument to determine whether a node is detached.
So yes, if we know that the node is attached parser.nodeOwnerDocument would yield the correct answer.

I actually now use the difference between getRootNode and nodeOwnerDocument to determine whether an element is or is not detached.