Skip to content

Prevent cumulative layout shift when rich workspace is loading - #4254

Closed
mejo- wants to merge 2 commits into
mainfrom
fix/richworkspace_no_cls
Closed

Prevent cumulative layout shift when rich workspace is loading#4254
mejo- wants to merge 2 commits into
mainfrom
fix/richworkspace_no_cls

Conversation

@mejo-

@mejo-mejo- commented Jun 7, 2023

Copy link
Copy Markdown
Member

📝 Summary

Instead of only increasing editor height with growing document length, let's stick to a fixed height (25vh) and use that one already while loading the document.

The editor height still increases when it gets focused.

🖼️ Screencasts

🏚️ Before🏡 After
recording1.webmrecording2.webm

🚧 TODO

  • Wait for feedback by @nextcloud/designers

🏁 Checklist

  • Code is properly formatted (npm run lint / npm run stylelint / composer run cs:check)
  • Sign-off message is added to all commits

@cypress

cypressBot commented Jun 7, 2023

Copy link
Copy Markdown

2 flaky tests on run #10169 ↗︎

014710Flakiness2

Details:

Prevent cumulative layout shift when rich workspace is loading
Project: TextCommit:748d58af57
Status: PassedDuration: 03:58 💡
Started: Jun 14, 2023 4:25 PMEnded: Jun 14, 2023 4:29 PM
Flakiness nodes/Links.spec.js • 1 flaky test

ViewOutputVideo

Test Artifacts
... > Link website with selection OutputScreenshots
Flakiness api/UsersApi.spec.js • 1 flaky test

ViewOutputVideo

Test Artifacts
The user mention API > fetches users with valid session OutputScreenshots

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.

@mejo-
mejo-force-pushed the fix/richworkspace_no_cls branch 2 times, most recently from ac816c8 to 12f6bfaCompareJune 7, 2023 17:51

@szaimenszaimen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for tackling this! 💙 It is actually my number one problem with rich workspaces and why I am usually disabling it.

I tested this and there is no jumping of elements anymore :) but it should not be shown if there is no readme.md file present right?
image

@marcoambrosinimarcoambrosini left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice improvement!

Instead of only increasing editor height with growing document length,
let's stick to a fixed height (25vh) and use that one already while
loading the document.
The editor still increases when it gets focused.
Fixes: #2834Fixes: #2803
Signed-off-by: Jonas <jonas@freesources.org>
@juliusknorr

Copy link
Copy Markdown
Member

The initial jumping is trickier as we'd need to know the availability of a rich workspace before the file list is loaded. We'd need a hook in the files app code to have a synchronous pass over of the propfind data to text before rendering.

@mejo-

Copy link
Copy Markdown
MemberAuthor

The initial jumping is trickier as we'd need to know the availability of a rich workspace before the file list is loaded. We'd need a hook in the files app code to have a synchronous pass over of the propfind data to text before rendering.

Indeed, I just discovered the same. So inside Text the only thing we can do, is reserve a fixed size for the rich workspace regardless of whether the Readme.md exists or not.

How about always limiting the height of non-focused rich workspace to 150px and make the toolbar display: none if not focused? Only on focus, the toolbar takes space and the editor is expanded? I pushed these changes to the PR now. See the following screencasts:

On large screenOn mobile screen
recording2.webmrecording1.webm

Instead of only increasing editor height with growing document length,
let's stick to a fixed height (150px) and use that one already while
loading the document.
The editor still increases when it gets focused.
Fixes: #2834Fixes: #2803
Signed-off-by: Jonas <jonas@freesources.org>
@mejo-
mejo-force-pushed the fix/richworkspace_no_cls branch from 12f6bfa to 748d58aCompareJune 14, 2023 16:23
@mejo-
mejo- requested a review from szaimenJune 14, 2023 16:23
@juliusknorr

Copy link
Copy Markdown
Member

I think we should try to find a way to prefetch the information, then we need no layout shift at all:

Some code paths that could be worth to investigate:

Point when the file list is loaded and being setup before rendering, possibly a good time to emit an event with the file list data? https://github.com/nextcloud/server/blob/8de29843497efed3eff05db1f90a15937d0a504c/apps/files/js/filelist.js#L2284

Maybe there is a way to extend the list of properties dynamically which is taken from https://github.com/nextcloud/server/blob/8de29843497efed3eff05db1f90a15937d0a504c/apps/files/js/filelist.js#L2199 when the file list does the PROPFIND.

We do something similar in group folders but I wouldn't reuse the code there due to the complexity and in depth dependency on files internals: https://github.com/nextcloud/groupfolders/blob/master/src/client.js#L141

@juliusknorr

Copy link
Copy Markdown
Member

Pushed a first draft of my suggested approach to #4776

Seems to work fine except for some quirks with the file list headers and dav properties when navigating around.

@mejo-

mejo- commented Sep 7, 2023

Copy link
Copy Markdown
MemberAuthor

Awesome, let's close this PR in favour of #4776 then.

@mejo-mejo- closed this Sep 7, 2023
@szaimen
szaimen deleted the fix/richworkspace_no_cls branch September 7, 2023 11:22
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3. to reviewdesign: papercutdesignExperience, interaction, interface, …ux

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Avoid cumulative layout shifts on Files pages [Bug]: The Directory List in files is rendered and then moves again after couple of ms.

4 participants

@mejo-@juliusknorr@marcoambrosini@szaimen