-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Try to fix Popover obstructs blocks #43162
Conversation
Size Change: +544 B (0%) Total Size: 1.27 MB
ℹ️ View Unchanged
|
Looks very promising in testing. I realise this is still a draft, but it'd be great to add more comments to the calculations to describe what each on does as that will make it easier to review. The only thing I'd consider as a nice addition to the current state of the PR is for the block to stay in place when scrolling if it's below the reference. Currently if the toolbar is below a block at the top of the canvas, when scrolling down it moves back to the top. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for working on this, Nik! The code in this PR is very interesting 👀
it'd be great to add more comments to the calculations to describe what each on does as that will make it easier to review
I have the same feedback — having comments would definitely help reviewing this PR.
For example, which bits are targeted at fixing this placement issue ?
Also tries to solve: Block Toolbar Regression - Toolbar obstructs selected blocks(#41575)
While this PR seems promising in terms of results, I would personally prefer a solution where we try to minimize the amount of custom middleware code in Popover
and rely more on standard floating-ui
features as much as possible — especially since it looks like the behavior that we're implementing here is quite fitter to the block toolbar.
The way this problem could be abstracted, in my mind, could be to:
- keep track, for each block, of the block's offset from the top of the page (and recalculate it only when necessary — i.e. not on page scroll)
- when the block toolbar is rendered, check if the selected block has a gap from the top of the page that can fit the toolbar (including the toolbar`s offset)
- if the gap isn't enough, turn on the
flip
middleware on thePopover
(via a prop that we should probably add)
(this, by the way, is very similar to the feedback that I left on #42887)
I've updated floating-ui to the latest version as I needed it for this change.
We should probably update the version of floating-ui
anyway in a separate PR
// If the reference has no height we don't need to do anything. | ||
referenceRect[ mainDimension ] && | ||
referenceRect[ mainAxis ] < 0 && | ||
ownerDocument.documentElement.scrollTop <= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just flagging that reading the scrollTop
property could cause reflow / layout trashing, which could affect the page's performance (especially since this middleware is computed as the user scrolls and interacts with the page)
Agreed on closing this PR, although I'll keep it mind as a source of inspiration for future Popover work. Thank you @ntsekouras for you work here ! |
What?
Partially based on #42950 for
Popover: fix shifting behavior to avoid popover overlapping its anchor
. This PR attempts to also handle theleft
placement issue.
Also tries to solve:
Block Toolbar Regression - Toolbar obstructs selected blocks
(#41575)I've updated floating-ui to the latest version as I needed it for this change.