-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Show insertion point after the last block in a container #28418
Conversation
Size Change: -21 kB (-2%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
Thanks! Would probably review it next week. Could you also help to uncomment the tests we commented out before? Just want to make sure we pass the tests 😉. |
I think the test might have been refactored entirely, can't seem to find them. |
nevermind, I was looking at the wrong test :) |
Seems like this test (https://github.com/WordPress/gutenberg/pull/28418/checks?check_run_id=1760742282) is failing for whatever reason 🤔, could you please take a look :) ? |
@kevin940726 It should be fixed now. |
In #25849, there's a fix to show the indicator in between two blocks when the former one is selected (See the screenshot in the PR). When trying this in this PR, it seems like it's not working anymore (seems intermittently). Any idea why? Is this intentional? Kapture.2021-01-26.at.10.21.46.mp4Also, perhaps we should start writing some e2e tests for the insertion indicator to avoid regressions in the future. |
I think the bug here is not in the current PR. It seems the issue is the fact that the insertion point in the state (reducer) is actually not "reset" properly when you open the inserter a second time. I believe this might be related to the fix @noisysocks or @talldan worked on to fix the position of the insertion after clicking "Browse All". I'm not really sure I understand the logic of that fix properly but it seems we're missing a reset at some point. |
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.
LGTM 👍
Probably could use some comments to better understand the code though 😅
It's great to see this work coming along. I was curious to see what the inserter button looked like in cases where the default block appender is already showing (at the ends of some block lists) and that is a bit funny but I found something else that is probably of greater concern. When using the inserter button that appears at the end of a block list, a newly inserted block gets inserted based on the location of the selected block instead of the inserter button. I made a recording with three uses of the same inserter button and three different places where a block gets inserted. None of them the expected position: insertion-after-selected.mp4 |
good catch @stokesman I think it's fixed now. |
The failing e2e tests here are a Core regression tracked here https://core.trac.wordpress.org/ticket/50025 |
@youknowriad testing #28382 i got this weird behavior with the inserter not being removed. Can you think of anything from this PR that may be the cause, so I can open an informed issue? ghost-inserter.mp4 |
@draganescu I don't know really on top of my mind, the interactions here are a bit complex and I didn't test nested menus in popovers. Please do track this. |
follow-up to #27860 (merge in the same changelog entry)
closes #28381
After #27860 the insertion point (in between inserter) only shows up between two blocks due to a complex positioning logic (center it properly between blocks both vertically and horizontally), this had the side effect of removing the possibility to show at the end of the block list (for instance by selecting the last block, opening the inserter and hovering a block type).
This PR solves that by considering a potential nullable next element.
There was also another issue where the hovering a block type in the inserter was showing the wrong insertion point indicator.