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

Multi-line Post title height is too short on load (intermittent) #6897

Closed
afercia opened this issue May 22, 2018 · 21 comments · Fixed by #31569
Closed

Multi-line Post title height is too short on load (intermittent) #6897

afercia opened this issue May 22, 2018 · 21 comments · Fixed by #31569
Labels
[Package] Editor /packages/editor [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
Milestone

Comments

@afercia
Copy link
Contributor

afercia commented May 22, 2018

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:

screen shot 2018-05-22 at 17 00 20

Them just refreshing the page fixes the title height:

screen shot 2018-05-22 at 17 00 33

To Reproduce

  • as said, doesn't happen consistently
  • I'd suggest to empty the Firefox cache first
  • then just go in the demo page
  • try a few times, navigating away and then navigating back to the demo page
  • the length of the content might play a role (increasing JS execution time)

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).

@danielbachhuber
Copy link
Member

Regardless, seems the height calculation is not so reliable and some improvements should be considered.

What improvements would you suggest?

@afercia
Copy link
Contributor Author

afercia commented May 23, 2018

One that doesn't make the title look cut-off 😉

@danielbachhuber danielbachhuber added the [Type] Bug An existing feature does not function as intended label May 23, 2018
@danielbachhuber danielbachhuber added this to the WordPress 5.0 milestone May 23, 2018
@tofumatt
Copy link
Member

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 😄

@tofumatt
Copy link
Member

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.

@mcsf mcsf added the Browser Issues Issues or PRs that are related to browser specific problems label Jul 19, 2018
@mcsf
Copy link
Contributor

mcsf commented Jul 19, 2018

@afercia, is the issue still reproducible?

@afercia
Copy link
Contributor Author

afercia commented Jul 19, 2018

@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:

screenshot 39

@designsimply
Copy link
Member

designsimply commented Aug 14, 2018

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

@designsimply designsimply added the Needs Testing Needs further testing to be confirmed. label Aug 14, 2018
@tofumatt tofumatt changed the title Post title height in Firefox incorrectly set Multi-line Post title height is too short on load (intermittent) Sep 30, 2018
@tofumatt
Copy link
Member

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.

@mtias mtias added the [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later label Oct 12, 2018
@ellatrix
Copy link
Member

I see this every time I open the demo post in Safari.

screen shot 2018-10-31 at 11 24 40

@designsimply
Copy link
Member

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.

@GlennMartin1
Copy link

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

@designsimply
Copy link
Member

Noting some testing steps from a duplicate issue at #11580 that look worth trying out:

  1. Add a new post
  2. Give the post a long(ish) title
  3. Open the settings
  4. Height doesn't change, resulting in the text clipping
  • OS: WIN10
  • Browser: Chrome
  • Version: Latest
  • Gutenberg 4.2

@NewJenk
Copy link

NewJenk commented Nov 8, 2018

Here's a video showing this issue on Chrome, Edge and IE: https://www.useloom.com/share/63aa55f131de407ca4501c383908ffcf.

@designsimply
Copy link
Member

designsimply commented Nov 15, 2018

@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

screen shot 2018-11-15 at 12 00 32 pm
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.

@designsimply designsimply removed the Needs Testing Needs further testing to be confirmed. label Nov 15, 2018
@youknowriad
Copy link
Contributor

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.

@garretthyder
Copy link
Contributor

garretthyder commented Nov 15, 2019

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;
feaa80f65c55f848a266cb602c85145d

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

@youknowriad
Copy link
Contributor

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.

@adamziel
Copy link
Contributor

adamziel commented Apr 22, 2020

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.
  • Resizing means setting a fixed height to fit all the content and overflow: hidden.
  • Once the title textarea is initialized, adjusting it's height occurs only in response to a fixed set of events (input, keyup, autosize:update fired on the input, window resize).
  • Opening the inspector does not trigger any of these events so the height is not adjusted. The problem is only apparent when the inspector is rendered after the input, and also if the screen width is just right in relation to the text content of the title.

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:

  • Some kind of a editorResize event that would be dispatched in circumstances like opening the inspector.
  • A wrapper around <TextareAutosize /> that would listen to that event and then dispatch autosize:update on the textarea node itself.

... or maybe we could leverage useResizeObserver?

@adamziel adamziel added [Package] Editor /packages/editor and removed Browser Issues Issues or PRs that are related to browser specific problems labels Apr 22, 2020
@youknowriad
Copy link
Contributor

youknowriad commented Apr 23, 2020

@adamziel Thanks for digging in, no strong preferences there, is there another library that already implement the right handlers maybe?

@ellatrix
Copy link
Member

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.

@paaljoachim
Copy link
Contributor

It would be great to get some forward movement here to find a solution so we can get this issue fixed.
Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Editor /packages/editor [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

Successfully merging a pull request may close this issue.