The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +44 B (0%)

Total Size: 2.2 MB

_{compressed-size-action}

Flaky tests detected in c73f774.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18602854315
📝 Reported issues:

• [Flaky Test] Create a pattern with overrides #58009 in /test/e2e/specs/editor/various/pattern-overrides.spec.js
• [Flaky Test] ensures List View global shortcut works properly #51533 in /test/e2e/specs/editor/various/list-view.spec.js
• [Flaky Test] should refresh the page when stylesheet loading fails #71722 in /test/e2e/specs/interactivity/router-styles.spec.ts

Thanks for the video. I wouldn't extend the canvas to fit the comments if we can find an alternative. I don't think we character limit notes, so inevitably they can become very long, and I believe how we elide and collapse is going to be something we evolve over time, such as always collapsing comments with a "read more" when they are longer than n characters, and even collapsing threads when there are more than n comments. I have a feeling @jarekmorawski may hae instincts around this.

But for the immediate future, I wonder if we can apply a max-height to comments, and then allow them to scroll. We might need canvas extension for extreme cases, after all, but we probably still need to pair that with scrolling. What do you think?

I can confirm that this fixes the mentioned issue. But I agree that there's room for improvement.

Currently, if you have notes with a large body of text, some notes for remaining blocks might not be visible. Also, when replying to a large note, there is no way to scroll up to the previous comment, which will make actual replies harder.

Screencast

Currently, if you have notes with a large body of text, some notes for remaining blocks might not be visible. Also, when replying to a large note, there is no way to scroll up to the previous comment, which will make actual replies harder.

Yeah, I just tested the PR and you cannot read the top of the comments, so I'm not sure how usable it's going to be this way either. I haven't checked this feature much and possible technical restrictions, but I'd expect some kind of overflow/scrollbars to be the proper fix..

Yeah, I just tested the PR and you cannot read the top of the comments, so I'm not sure how usable it's going to be this way either. I haven't checked this feature much and possible technical restrictions, but I'd expect some kind of overflow/scrollbars to be the proper fix..

True. Still, the most important part is being able to add a new comment, which this PR addresses.

One way to fix the top cutoff would be if the user scrolled to the top, push the notes down from the top. Another idea is making the notes themselves scrollable.

One way to fix the top cutoff would be if the user scrolled to the top, push the notes down from the top. Another idea is making the notes themselves scrollable.

I'm more in favor of the former and not the later, meaning I'd prefer to avoid another scrollbar/scrolling experience specific for notes. In testing in Google Docs, seems as though they treat comments there as within the doc canvas itself where the doc can scroll out of view if comments are lengthy enough. That handling won't work (or at least feels suboptimal) within Gutenberg, so aiming for the "if the user scrolled to the top, push the notes down from the top" would be my preference.

Currently, if you have notes with a large body of text, some notes for remaining blocks might not be visible. Also, when replying to a large note, there is no way to scroll up to the previous comment, which will make actual replies harder.

aiming for the "if the user scrolled to the top, push the notes down from the top" would be my preference.

I'm going to work on this idea - if the user scrolls to the top of the editor while commenting on a thread, we can push down the thread so it doesn't overlap there as well.

We will still have an edge case where you create a very short post with no scrolling, then add a very long comment thread. Perhaps the best solution would be to detect this scenario and use an alternate solution in that instance such as making the thread itself be scrollable.

@jeffpaul I gave #72547 a test and was surprised how well it works, can you give it a try? You can test in in Playground. It does add scrolling, but its a fairly intuitive and browser native approach.

@adamsilverstein I concur, testing that Playground link for 72547 is a definite improvement. Any immediate concerns you have with moving towards merging that in place of this PR (asked differently, anything from this PR that you feel pairs well with the work in 72547)?

@adamsilverstein I concur, testing that Playground link for 72547 is a definite improvement. Any immediate concerns you have with moving towards merging that in place of this PR (asked differently, anything from this PR that you feel pairs well with the work in 72547)?

No, but for completeness sake, I also created a PR to test out the idea of resizing the editor iframe (body) to set its min-height to match the notes required space. Has some rough edges, but gets the idea across: #72811

Closing in favor of #72811