-
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
Make sure we don't search the directory for child items. #24148
Make sure we don't search the directory for child items. #24148
Conversation
Size Change: +52 B (0%) Total Size: 1.18 MB
ℹ️ View Unchanged
|
@StevenDufresne Do you consider this a 5.5 blocker, or as I suspect, it can wait for 5.5.1? |
It's tough to tell but probably not a blocker seeing that it seems to be specific to blocks with parent/child relationships and at this moment in time there are few blocks written that way. |
For some reason, this only works when I'm in the heading section of Cornell Notes. I'm also able to search the block directory within this restricted container block, and like you mention above, it shows like this even though Waves is installed. |
@ryelle Thanks for taking a look. I'll investigate some of the other pathways. In the meantime, I've switched this to a draft. |
I pulled this branch and locally rebased it on master, and I still see the same as above. Here's a screencast of the allowedBlocks issue, in case that's not clear: https://cloudup.com/cQU24Wu9_3t On this branch I see the expected (no blocks found) when in the Cornell Notes header, though TBH I'm not sure what the difference is between my example block above and the Cornell Notes block that makes it work here but not there. |
@ryelle Thanks for the screenshot. That was definitely helpful and I see what you are saying. I don't think that behavior is necessarily connected to the problem this PR is trying to address. This PR makes sure we don't search the block directory when we are focused 'in' a block. Now, the fact that you can't have active focus on a parent block and the main inserter open, since #24429, this problem goes away from a user's perspective (the quick inserter doesn't support the block directory yet). The code is still a problem should we ever revert back the functionality from #24429. Looking at the video, as you click to open the The fact that the block you installed shows up in search is the problem you filed in #24560. It's related to the way the inserter filters out blocks. |
No, the currently selected block is still the restricted parent— you can see before I start typing in the video that only the 3 block types are available to me.
I'm not sure what you mean here. The cursor's focus moves out of the block, but the editor still tracks that block as "selected". |
609eb9c
to
e869633
Compare
You are correct. I missed that it's only showing the restricted blocks. The difference is most likely that you don't have a parent/child relationship. This PR stops the searches when there are children blocks. I'll look into stopping if it has |
11b8ff3
to
1c679d5
Compare
1c679d5
to
8244866
Compare
@ryelle Do you mind taking a look at this again when you get a chance? |
I don't think we can assume having allowedBlocks will mean that block-directory blocks would not be allowed, so just disabling the BD results doesn't really fix the larger problem. We should be checking "permission" for each block before showing them to the user. I think I've managed to do that in this PR: #25926 |
Description
This PR makes sure that we don't search the block directory when we are displaying the child blocks otherwise the block inserter does not recognize that the block was already installed.
How to replicate the issue?
Why is this happening?
This problem occurs because the block enforces children blocks and this leads to 2 problems:
rootClientId
changes emptyingfilteredItems
and therefore showing the block directory component.Types of changes
hasChildItems
&hasAllowedBlocks
into the slot/fill and returnnull
in the Block Directory package plugin component should either match.Question/Improvements
After the block installs, we move the focus into the block. Since the
filterValue
doesn't match the name of the child block, the user seesno results
in the inserter.You can view the behaviour here (with the fix to stop searching the block directory): https://d.pr/v/QDVQ0p.
Should we clear the filter value for blocks with children blocks?
Checklist: