Size Change: -4.01 kB (0%)

Total Size: 1.34 MB

_{compressed-size-action}

Flaky tests detected in 9f254c0.
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/4554910986
📝 Reported issues:

• [Flaky Test] should be able to create an hierarchical post without title support #36939 in specs/editor/plugins/custom-post-types.test.js
• [Flaky Test] shows changes in a template when a template part it contains is modified #42139 in /test/e2e/specs/site-editor/template-part.spec.js

I happened to be working on a similar problem in #39619.

PlainText uses an internal EditableText component when the experimental version is 2. On the other hand, if no version is specified, it uses the TextareaAutosize component. The effort is to stabilize version 2 and deprecate version 1 to avoid the use of unmaintained react-autosize-textarea.

However, as noted in this comment, PlainText version 2 removes HTML tags, so it cannot be used in the HTML block or the shortcode block, for example. If this PR is merged, Those two blocks could be solved by using the new react-textarea-autosize directly.

I will be happy to help with testing!

One issue I found so far is that the initial text height is incorrect in some situations. I could only verify this bug in Firefox, not Chrome or Safari.

Switch to code editor. Initial height will be incorrect.
Type something or open the dev tools and the height will be correct
Reload the page -- it'll stay in code editor, and the height will be correct this time.
Switch back to normal editor, and then back to code editor. Height will be correct.
Switch back to normal editor, and reload the page. Then open the code editor. Height will be incorrect

I tested it on Windows. Unless my procedure was incorrect, the problem did not reproduce. Is this an OS issue_?

I have tested both Chrome and Firefox on Windows OS.

• ✅ The BlockHTML component in block-editor (used in the block list in "html" mode)
• ⚠️The PlainText component in block-editor
• ✅ The CodeEditorTextArea component in edit-site
• ✅ The PostTextEditor component in editor

As for the PlainText component, I only tested the version 1 one. This is because react-textarea-autosize is not used in version 2.

In the two blocks using PlainText (HTML Block, Search Block), I found the following problems:

Switching to the code editor and back to the normal editor. Height will be incorrect. Occurs only in Chrome.

Switching to the code editor for the first time, the HTML will cut off. Occurs only in Firefox.

As for the React Native app, I can't test it, but the version 1 PlainText component is used in the following three places:

I tested it on Windows. Unless my procedure was incorrect, the problem did not reproduce. Is this an OS issue_?

It could be -- I'm on Firefox in macOS. However, the issues you noted sound very similar to that one :) In your first video, I don't think there is enough text in the editor to trigger the bug (it has to be longer than the default minimum height)

Here's my video of the problem: https://user-images.githubusercontent.com/6265975/219794503-2f3282f2-0395-4839-a3e7-f7dc115d0131.mp4

It sounds like we are blocked until we can get the maintainer to release a new version :( There is a proposed fix (Andarist/react-textarea-autosize#353), which might solve these problems for us. However, it doesn't look like the maintainer has been active in the past few weeks.

I don't think we can reasonably fix the bug on our side

In your first video, I don't think there is enough text in the editor to trigger the bug

You're right, I was also able to reproduce this problem in Windows OS.

In the two blocks using PlainText (HTML Block, Search Block), I found the following problems:
Switching to the code editor and back to the normal editor. Height will be incorrect. Occurs only in Chrome.

If you don't mind, could you test if this problem reproduces on MacOS as well? The proposed fix (Andarist/react-textarea-autosize#353) appears to be for firefox, so even if a fixed version is released, this issue might not be resolved.

The fix was merged in that repo, so hopefully it'll make it to npm in the next day or two, at which point I'll revisit this and test that scenario!

v8.4.1, which fixes bugs related to Firefox, has been released. How about incorporating this package into this PR and testing it again?

I tried this PR again with the latest version of react-textarea-autosize incorporated, but the problem remained 😅

I cannot determine which side this problem is on, but if you click on the textarea or resize the screen, the correct height is set. I'm wondering to figure out if we can make this work...

Update:

A new PR has been submitted on this issue in the react-textarea-autosize repository. This PR also seems to be related to height recalculation, so let's confirm this again when this is merged.

Nice, thanks for the update!

Update: I saw a tweet suggesting that the native textarea element might auto-adjust its height.

In the future, if this is supported by major browsers, we may be able to solve this problem without relying on libraries 😊

Btw, we could completely simulate a textarea with a contenteditable div, which we do now with PlainText, but there could be some unfixed issues and currently PlainText is only available for blocks, where it's more important to use different tag names.

Ideally we should deprecate PlainText version 1, as said earlier, so that's one use of textarea less.

PlainText version 2 removes HTML tags

Yes, we should fix that (I can't remember the reasons there)

I'm going to close the PR -- the fixes still haven't been shipped to the library, and I won't have time to work on this any more. Plus, Ella's idea sounds more ideal