Skip to content
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

List View: Stale windowing logic when switching between content and template in site editor when no content block is present #56360

Open
andrewserong opened this issue Nov 21, 2023 · 0 comments
Labels
[Feature] List View Menu item in the top toolbar to select blocks from a list of links. [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Bug An existing feature does not function as intended

Comments

@andrewserong
Copy link
Contributor

Description

This issue is pretty edge-casey (and therefore low priority), but I noticed it while testing out #56326. When switching between the content only and template editing modes in the site editor (while viewing a particular page of a site), there's nothing that explicitly tells the windowing logic for the list view to update.

This means that in a page whose template does not include a Content block, if we switch to the template mode, and that template has a large number of blocks (enough to usually trigger the windowing logic), then it's possible to get into a state where scrolling the template does not update the windowing, and a user cannot see the items in the list.

It turns out the likely culprit is that when a template does not contain any content blocks, then switching between the content only or template modes does not update the getGlobalBlockCount used to calculate visibleBlockCount for the list view's windowing logic, and that value is used to figure out when to refresh the windowing logic.

To resolve this (likely low priority issue) I believe we'll want to inspect clientIdsTree which is returned by useListViewClientIds and use a change to that tree as an indicator that the windowing logic should be updated. We might want to be careful doing that, though, that we don't look at the value too frequently, for performance concerns.

Step-by-step reproduction instructions

  1. Create a template with a large number of blocks, enough to trigger the list view's windowing logic. E.g. 60 or so.
  2. Create a page, and select this template, and publish it
  3. Now, go to the site editor and go to edit this page
  4. From the content view, go to edit the template
  5. Once editing the template, notice that the list view's windowing logic does not update

Screenshots, screen recording, code snippet

In the below screengrab, we first load a page in the site editor which is using a template that does not contain a Content block. In this example, we assume a user might be intending to go to the template in order to add the block somewhere. However, after switching to the template mode, the list view does not update to reflect the windowing logic that should be used. (Note that if a user expands or collapses any blocks, the windowing logic will update):

2023-11-21.16.43.11.mp4

Environment info

  • WP 6.4.1
  • Gutenberg trunk

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@andrewserong andrewserong added [Type] Bug An existing feature does not function as intended [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Feature] List View Menu item in the top toolbar to select blocks from a list of links. labels Nov 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] List View Menu item in the top toolbar to select blocks from a list of links. [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

1 participant