Fix co-ordinate issue with display: contents nodes #177
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/support-display-contents-nodes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I observed a bug with a custom table component I have implemented, based on
prosemirror-tables. The issue arises from a conditional check inposAtCaretwhich 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
Would incorrectly return
table.posAfterfromposAtCaretinstead of the pos of the internal<pnodeThe problematic line is here
https://github.com/ProseMirror/prosemirror-view/pull/177/files#diff-8711f18f44af6275714f55277ddd18fb124ab348b03cd4b86a4fdb253b205330R241
An element with
display: contentswill 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
@ -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.Happy to update this comment - its maybe not very descriptive.
Does alternative patch
bbd0ab2solve this for you?Pull request closed