Describe the bug
Couldn't reproduce consistently but _sometimes_ the post title height in Firefox is not correctly calculated, so the post title is not entirely visible.
I guess it has something to do with timings and the speed different browsers load content and execute JS. Worth also checking with other browsers. Regardless, seems the height calculation is not so reliable and some improvements should be considered.
What I often see in Firefox is this:

Them just refreshing the page fixes the title height:

To Reproduce
Tested on a macbook pro and Firefox 60.
Worth also considering what might happen on a less performant machine (where the JS execution is likely slower).
Regardless, seems the height calculation is not so reliable and some improvements should be considered.
What improvements would you suggest?
One that doesn't make the title look cut-off 馃槈
What improvements would you suggest?
It's okay to file an issue without an accompanying solution; we shouldn't make folks feel like they need to both file the issue and present the fix 馃槃
I was able to get this to reproduce but it is intermittent (so probably some kind of race condition).
On macOS it helped to throttle down Firefox's Web Content process using AppPolice.
I had to load the page about a dozen times in Firefox 61, but eventually it did happen.
@afercia, is the issue still reproducible?
@mcsf I still can reproduce it, randomly. I've noticed it's easier to reproduce in Firefox after clearing the browser's cache. It happens also on Windows, randomly. Even when it works correctly, on Windows there's a "jump" when the page loads that is always noticeable and unfortunately seeing a big Windows scrollbar in the title block is not that great:

Closed #8930 as a duplicate and noting that they tested with:
Safari 11.1.2
Mac OS 10.13.6
Screen Resolution 1680 x 1050
Web Browser Size 1579 x 931
Installed/activated browser extensions: Ghostery and 1Password
Based on #7255, it seems this can happen in browsers other than Firefox, but it's quite hard to reproduce. I still can't manage it though.
I see this _every_ time I open the demo post in Safari.

I tried replicating the problem using Safari 12.0 on macOS 10.13.6 and the height of the title looks normal to me (screenshot). I tested with WordPress 4.9.8 and Gutenberg 4.2.0-rc.1 using Safari 12.0 on macOS 10.13.6. I tried with Unified Toolbar on and off as well as Fullscreen Mode on and off.
I'm leaving the Needs Testing label for now because we still want to figure out reliable steps to reproduce the problem. If you can think of any browser settings you may have that are not standard (i.e. modified font size) or if you have a browser extension or add-on that modifies content or if you aren't using the latest stable version of your browser, please leave a note with details.
I used to have it happen frequently in Chrome (Windows), but I haven't seen it in a while.
I'm unable to replicate it now using 4.1 or 4.2.0-rc.1.
Some bugs fix themselves?! lol
Noting some testing steps from a duplicate issue at #11580 that look worth trying out:
- Add a new post
- Give the post a long(ish) title
- Open the settings
- Height doesn't change, resulting in the text clipping
- OS: WIN10
- Browser: Chrome
- Version: Latest
- Gutenberg 4.2
Here's a video showing this issue on Chrome, Edge and IE: https://www.useloom.com/share/63aa55f131de407ca4501c383908ffcf.
@NewJenk I noticed you used https://frontenberg.tomjn.com/ for testing so I re-tested with that (appears to be running Gutenberg 4.3) using Edge 17 and Chrome 70 on Windows 10 and I found that I could see some clipping of the title appear but I had to bump up the font size in order to see the problem and then I could see it in Edge but not in Chrome and only if the title was long enough to fall to four lines and not three as in your video. (39s)
I also re-tested with https://frontenberg.tomjn.com using Safari 12.0 on macOS 10.13.6 and found I could see the title clipped without opening the settings sidebar or changing the zoom level in the browser. If I refresh the page, the problem goes away and doesn't come back unless I completely shut down Safari and then re-open. I spotted some errors in the console but I am not sure if they are related:
Unhandled Promis Rejection: Error [object Object]
https://frontenberg.tomjn.com/wp-content/plugins/gutenberg/vendor/wp-polyfill.min.2ae96136.js

Seen at https://frontenberg.tomjn.com running WordPress 4.9.8 and Gutenberg 4.3 using Firefox 63.0.1 on macOS 10.13.6.
This bug is related to our react-autosize-textarea npm dependency. We're using a very old version of that dependency, we should try updating it to see if it fixes the issue.
Hi @youknowriad is there a way to test the npm dependency on a local install?
On a clean install of trunk (post-5.3) going to the Privacy Policy page to edit while having the browser half-width of a mac pro laptop I'm able to consistently reproduce. If you click into the input area the height adjusts and upon reload it looks ok... but if you do a hard refresh (Chrome) cmd+shift+r the issue will return.
Screen;

The clean install to reproduce is done as follows using MAMP;
svn co https://develop.svn.wordpress.org/trunk/ .
npm install
grunt build
Setup SQL
Install
Navigate to edit Privacy Policy page
Click into edit, reload (seems fixed)
hard refresh (cmd+shift+r) issue returns
Browser size 960w
Chrome 77.0.3865.90
Mac OS X 10.11.6
Hi聽@youknowriad聽is there a way to test the npm dependency on a local install?
No, that's not possible because this dependency is bundled in the JS code.
This bug is related to our react-autosize-textarea npm dependency. We're using a very old version of that dependency, we should try updating it to see if it fixes the issue.
@youknowriad I just tried updating react-autosize-textarea to 7.0.0 (latest ATM) doesn't help. I traced the root cause of the problem:
react-autosize-textarea uses autosize library to handle resizing.overflow: hidden.input, keyup, autosize:update fired on the input, window resize).To add to the complexity, manually dispatching window resize event won't help as autosize caches the clientWidth and only triggers a resize when it actually changes.
It seems like a proper fix would involve:
editorResize event that would be dispatched in circumstances like opening the inspector.<TextareAutosize /> that would listen to that event and then dispatch autosize:update on the textarea node itself.... or maybe we could leverage useResizeObserver?
@adamziel Thanks for digging in, no strong preferences there, is there another library that already implement the right handlers maybe?
Ideally the post title should be a block using RichText or PlainText v2. There's some other issues with the post title that could benefit from this, like paste issues and special handling within writing flow.