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

Page constantly jumps when trying to scroll to bottom #8603

Closed
maddisondesigns opened this issue Aug 6, 2018 · 10 comments · Fixed by #10227
Closed

Page constantly jumps when trying to scroll to bottom #8603

maddisondesigns opened this issue Aug 6, 2018 · 10 comments · Fixed by #10227
Labels
[Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later

Comments

@maddisondesigns
Copy link

Describe the bug
I've had this happen quite a few times recently. After previewing a page (in another tab), I returned to the edit screen to make some changes. When I try to scroll to the bottom of the page, the page keeps scrolling itself updwards whenever I try to scroll down. If you look at the following vid, when I try to scroll all the way down the page, you can see that the page keeps scrolling back up half a page or so, and it wont actually let me scroll all the way down.

You'll also notice that as I scroll back up the page, there's a huge blank space above the Vimeo embed. Once I stop scrolling, the video seems to jump back to it's proper position and the gap disappears, until I scroll down and back up again.

https://cl.ly/1b0b2P3X0q0s

To Reproduce
Steps to reproduce the behavior:
I don't know how to reproduce it sorry. It seems to happen randomly. I do know that I've had it happen quite a few times though. The page in the vid is the default Gutenberg post

Desktop (please complete the following information):

  • OS: macOS Sierra 10.12.6
  • Browser: Firefox Quantum 61.0.1 (64-bit)
  • Version: Gutenberg 3.4.0
@designsimply designsimply added [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... Needs Testing Needs further testing to be confirmed. labels Aug 7, 2018
@designsimply
Copy link
Member

I was able to reproduce the problem using the following extremely specific steps:

  1. Go to WP Admin > Gutenberg to open the demo.
  2. Scroll down until you see the Vimeo embed block.
  3. Hover over the block until you see the mouse turn into a hand indicating you are on the draggable handle for the block and click (note: the draggable handles are currently on the right and left and are subject to change, see Drag & Drop: Change to use hover label as the draggable handle #7114).
  4. Place the cursor into the very middle so that it will be hovering over other existing blocks and not to the right or left of them.
  5. Continue scrolling down with the mouse to the end of the content while the Vimeo video block is still selected and in drag-and-drop mode.

Result: if you have both selected an embed block's draggable handles and scroll down over the top of other blocks at the same time, the editor will scroll back up to the currently selected block that is designated as ready to drag-and-drop. The problem does not happen if the selected block is not in drag-and-drop mode and if the mouse is not hovered over other blocks during scroll. (1m26s)

Possible solution: ditch drag-and-drop mode for items that are scrolled out of view.

Note: I am not sure how technically feasible or easy this is to address—it's worth considering whether or not there is a good tradeoff here to adding code in order to alleviate the extremely specific set of steps it takes to get into this rather odd state. I'd say go for it if it can be solved simply but skip it if it would take a ton of code to address. 🙂 Because of that I am marking this issue as low priority.

@designsimply designsimply added [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later and removed Needs Testing Needs further testing to be confirmed. labels Aug 7, 2018
@maddisondesigns
Copy link
Author

@designsimply I just followed your steps and I found it's actually easier to reproduce than that. You don't need to do your Step 3. All you need to do is select the Vimeo block and then move the cursor below it (hovering over the other blocks) and then keep scrolling.

Here's another vid - https://cl.ly/1K0V3X312r32

jasmussen added a commit that referenced this issue Sep 28, 2018
This, I think, fixes #8603.

I wasn't able to reproduce the exact issue, but I was able to reproduce a different one which I think is the same minus some browser behavior differences.

Essentially, when you don't scroll the `body` but instead scroll an element, once you've scrolled to the end of that element, pause, and then try to scroll further, browsers now try to scroll the _parent_ element, in this case `body`. But because that isn't scrollable, some browsers apply an "overscroll bounce", others just prevent scrolling, even upwards.

Steps to reproduce:

1. Have a page with enough content to create a scrollbar.
2. Scroll to the very end of that content.
3. Hold a brief pause in scrolling.
4. Now in one motion first scroll downwards and then immediately start scrolling upwards.

Observe that you're not scrolling anywhere, or you're invoking overscroll bounces.

Step 4 is crucial — it is BECAUSE we start by scrolling _downwards_ that the browser decides to try and scroll the body element instead of the element we mean to scroll (`.edit-post-layout__content`), and because the body can't be scrolled, this is causing the issue.

This PR fixes that.
@jasmussen
Copy link
Contributor

In #10227 I believe I fixed this issue.

Thanks for the detailed report and steps to reproduce. I tried a bunch of things and for the longest time I couldn't reproduce. I think this is due to various browser, operating system behaviors, and mouse defaults.

But in the end I was able to reproduce an issue that, although it didn't create bounces in my situation, I BELIEVE it's the same issue. From the ticket here's how I reproduced that issue:

Steps to reproduce:

  1. Have a page with enough content to create a scrollbar.
  2. Scroll to the very end of that content.
  3. Hold a brief pause in scrolling.
  4. Now in one motion first scroll downwards and then immediately start scrolling upwards.

Observe that you're not scrolling anywhere, or you're invoking overscroll bounces.

Step 4 is crucial — it is BECAUSE we start by scrolling downwards that the browser decides to try and scroll the body element instead of the element we mean to scroll (.edit-post-layout__content), and because the body can't be scrolled, this is causing the issue.

Can you try the PR and see if it fixes the issue?

@designsimply designsimply added the Needs Testing Needs further testing to be confirmed. label Sep 28, 2018
jasmussen added a commit that referenced this issue Sep 30, 2018
This, I think, fixes #8603.

I wasn't able to reproduce the exact issue, but I was able to reproduce a different one which I think is the same minus some browser behavior differences.

Essentially, when you don't scroll the `body` but instead scroll an element, once you've scrolled to the end of that element, pause, and then try to scroll further, browsers now try to scroll the _parent_ element, in this case `body`. But because that isn't scrollable, some browsers apply an "overscroll bounce", others just prevent scrolling, even upwards.

Steps to reproduce:

1. Have a page with enough content to create a scrollbar.
2. Scroll to the very end of that content.
3. Hold a brief pause in scrolling.
4. Now in one motion first scroll downwards and then immediately start scrolling upwards.

Observe that you're not scrolling anywhere, or you're invoking overscroll bounces.

Step 4 is crucial — it is BECAUSE we start by scrolling _downwards_ that the browser decides to try and scroll the body element instead of the element we mean to scroll (`.edit-post-layout__content`), and because the body can't be scrolled, this is causing the issue.

This PR fixes that.
@maddisondesigns
Copy link
Author

This issue is back again in 5.0 RC3. Can you please re-open this. You can't access any content under a video embed Block if one of them is selected

@designsimply designsimply reopened this Mar 13, 2019
@Soean
Copy link
Member

Soean commented Jun 13, 2019

I tested on the current Gutenberg version and can't reproduce it. @maddisondesigns does this issue still exist or can we close it?

@maddisondesigns
Copy link
Author

@Soean This is still an issue with WP 5.2.1 and v5.9.0 of the Gutenberg plugin.

After selecting a Vimeo block, the page is still jumping erratically when trying to scroll below it, and when scrolling back up, large gaps appear and disappear in your content.

Here's another vid: https://cl.ly/480ce9c32886

@maddisondesigns
Copy link
Author

This is also happening on YouTube Blocks now as well. Previously it only seemed to happen with Vimeo vids, but now the same thing is also happening with YouTube vids, which means it's gotten worse.

Tested with Gutenberg v6.4.0

@ehti
Copy link

ehti commented Mar 18, 2020

@maddisondesigns Using Chrome 80 and latest Firefox on macOS, Gutenberg 7.7.1, I tried to reproduce it but no luck. Are you still seeing the issue and if so, what's your environment? Fresh install as well?

@maddisondesigns
Copy link
Author

@ehti I just tried with Firefox 74.0 and WP5.4-RC3, and also with Gutenberg 7.7.1, and couldn't replicate it, so happy for you to close this one if you want.

@ehti ehti removed the Needs Testing Needs further testing to be confirmed. label Mar 19, 2020
@ehti
Copy link

ehti commented Mar 19, 2020

Thanks for confirming! 🙌

@ehti ehti closed this as completed Mar 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants