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

🐞 useDOMScrollLock sometimes scrolls page back to the top #10

Open
jd-solanki opened this issue Sep 11, 2022 · 7 comments
Open

🐞 useDOMScrollLock sometimes scrolls page back to the top #10

jd-solanki opened this issue Sep 11, 2022 · 7 comments
Labels
bug Something isn't working

Comments

@jd-solanki
Copy link
Owner

Steps to reproduce

Check dialog demos randomly multiple times you might get below bug where when you open the dialog window/page suddenly scrolls to the top
chrome-capture-2022-8-11

Notice when we click on show dialog page is scrolled to the top and when we close the dialog page is back to its position.

What is expected

It should not scroll back to the top when we click on show dialog button

What is actually happening?

Window/page is scrolled to the top when the dialog is visible

@jd-solanki jd-solanki added the bug Something isn't working label Sep 11, 2022
@jd-solanki jd-solanki changed the title 🐞 useDOMScrollLock composable sometimes sends back to the top 🐞 useDOMScrollLock sometimes scrolls page back to the top Sep 11, 2022
@brojor
Copy link
Contributor

brojor commented Sep 12, 2022

I could not reproduce this bug in Chrome 105.0.5195.102, Safari 15.6 (17613.3.9.1.5), or Firefox 104.0.2 (64 bit) on macOS Monterey 12.5

In firefox and safari browsers, there is a button in the dialog that shouldn't be there.
Kapture 2022-09-12 at 20 08 41

@jd-solanki
Copy link
Owner Author

The close button you are seeing in the width demo might be due to some glitch. Please clear the cache and reload the page, hopefully, it will go away.

Moreover, regarding reproducing the issue, you will open demos repeatedly & randomly and in around 20-30 seconds you will get the bug.

I hope this will help you.

@zguolee
Copy link
Contributor

zguolee commented Sep 19, 2022

I could not reproduce this bug in Chrome 105.0.5195.102, Safari 15.6 (17613.3.9.1.5), or Firefox 104.0.2 (64 bit) on macOS Monterey 12.5

It may be a bug of vitepress, and the reproduction process: directly enter the link(e.g.Dialog) and refresh the web page, and then it will appear, and even the content will not be available.

@jd-solanki
Copy link
Owner Author

jd-solanki commented Sep 19, 2022

@zguolee Bingo!

I thought It is from useDOMScrollLock.

Yes, the Close button in the width demo can be due to VitePress.

I am removing upstream label because the main issue is we are facing a scroll shift while opening dialog.

Maybe I should test this in fresh vuejs project without VitePress and update the issue.

@zguolee
Copy link
Contributor

zguolee commented Sep 19, 2022

@zguolee Bingo!

I thought It is from useDOMScrollLock.

Yes, the Close button in the width demo can be due to VitePress.

I am removing upstream label because the main issue is we are facing a scroll shift while opening dialog.

Maybe I should test this in fresh vuejs project without VitePress and update the issue.

There is no problem with building and preview only have warnings. When I refresh the production web, the browser console shows a Hydration completed but contains mismatches. error, which may be a deployment problem(vuejs/vitepress#1143)?

@jd-solanki
Copy link
Owner Author

Hey guys,

We have fixed SSR issues so we won't get Hydration completed but contains mismatches. 🥂

@hafiidz
Copy link

hafiidz commented Mar 9, 2023

Hi, not sure if I should post into a new thread, but mentioning it here first, on an unexpected UI behaviour when dialog shows up, in a page that's fit in screen (ie no scroll bar). Forcing a scroll lock in this situation result in creation of scroll bar and hence a jiggle effect where everything on screen is shifted to the left of the newly created scrollbar. This is tested on a Windows 11 Laptop, Chrome browser latest.

Expected behaviour is no scroll lock performed when a page is fit (and thus no existing scrollbar).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants