Fix co-ordinate issue with display: contents nodes #177

Closed
dan-cooke wants to merge 1 commit from fix/support-display-contents-nodes into master
dan-cooke commented 2024-12-10 16:50:45 +01:00 (Migrated from github.com)
  • I observed a bug with a custom table component I have implemented, based on prosemirror-tables . The issue arises from a conditional check in posAtCaret which will cause the position to use the doc.content.size when a zeroed out client rect is returned.

  • This commit adds an extra conditional check which will ignore any elements that have zero width and height. This seems like a sensible solution to me but please let me know if this is unwise.

Before this fix

A DOM setup like

<table>
     <tr><p>CARET</p></tr>
</table>
table {
   display: contents
}

Would incorrectly return table.posAfter from posAtCaret instead of the pos of the internal <p node

The problematic line is here

https://github.com/ProseMirror/prosemirror-view/pull/177/files#diff-8711f18f44af6275714f55277ddd18fb124ab348b03cd4b86a4fdb253b205330R241

An element with display: contents will have a zerod client bounding rect. So it will always descend into this branch.

I believe my change will handle other edge cases where an element has a zero'd bounding rects

* I observed a bug with a custom table component I have implemented, based on `prosemirror-tables` . The issue arises from a conditional check in `posAtCaret` which will cause the position to use the doc.content.size when a zeroed out client rect is returned. * This commit adds an extra conditional check which will ignore any elements that have zero width and height. This seems like a sensible solution to me but please let me know if this is unwise. ## Before this fix A DOM setup like ```.html <table> <tr><p>CARET</p></tr> </table> ``` ```.css table { display: contents } ``` Would incorrectly return `table.posAfter` from `posAtCaret` instead of the pos of the internal `<p` node The problematic line is here https://github.com/ProseMirror/prosemirror-view/pull/177/files#diff-8711f18f44af6275714f55277ddd18fb124ab348b03cd4b86a4fdb253b205330R241 An element with `display: contents` will have a zerod client bounding rect. So it will always descend into this branch. I believe my change will handle other edge cases where an element has a zero'd bounding rects
dan-cooke (Migrated from github.com) reviewed 2024-12-10 16:57:21 +01:00
@ -230,2 +230,4 @@
if (desc.dom.nodeType == 1 && (desc.node.isBlock && desc.parent || !desc.contentDOM)) {
let rect = (desc.dom as HTMLElement).getBoundingClientRect()
if (!rect.width && !rect.height) {
// its possible to have a node with display:contents, yet it contains other block nodes.
dan-cooke (Migrated from github.com) commented 2024-12-10 16:57:21 +01:00

Happy to update this comment - its maybe not very descriptive.

Happy to update this comment - its maybe not very descriptive.
marijnh commented 2024-12-11 07:42:16 +01:00 (Migrated from github.com)

Does alternative patch bbd0ab2 solve this for you?

Does alternative patch bbd0ab2 solve this for you?

Pull request closed

Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
prosemirror/prosemirror-view!177
No description provided.