WP admin doesn't scroll when on gutenberg screen

[m-e-h]

Issue Overview

I'm unable to scroll the wp-admin sidebar up or down. So I can't navigate to or view all of my post-types and menu-items.

Steps to Reproduce (for bugs)

1. Have taller sidebar menu than the view-port.

Chrome 65 and Firefox 57 on Ubuntu 16.04

Expected Behavior

Scroll the admin sidebar on the y-axis.

Current Behavior

Doesn't scroll.

Possible Solution

Rather than changing the overflow behavior on the entire wp-admin by declaring on the document body like this https://github.com/WordPress/gutenberg/blob/master/editor/assets/stylesheets/main.scss#L1-L8
Declare it on just the editor.
I'm not clear on what's being accomplished with this CSS but maybe add it somewhere like .gutenberg or #wpbody?

Screenshots / Video

[m-e-h]

Here are some better examples of the issue I'm seeing. (I have a ton of post-types)
These gifs include exactly what I'm seeing on my monitor. Nothing is cut off on the bottom.

Current CSS with overflow: hidden on the body:

I'm unable to scroll the rest of my left sidebar into view. And notice that the editor's scrollbar actually goes out of view, leaving it unknown where you are in the content.

Here is the overflow: hidden removed:

I'm able to scroll all of the sidebar into view, however, the scrollbar still disappears. I also notice the jank that was mentioned in this pr 353ee9c

Here, overflow: hidden is removed and I've added position: relative to .gutenberg since it wraps .gutenberg__editor which is position: absolute:

I'm able to scroll and the editor scrollbar stays in view.
The editor window does get a little out of sync since the document body continues to scroll the height of the sidebar once the editor has scrolled to it's end.
There's got to be a way to stick that editor to the bottom of the viewport. I'll have to play with it some more over the weekend.

[bamadesigner]

I am having the same issue. If my viewport is shorter than my admin content, I can't scroll outside of the Gutenberg edit area and therefore can't access my full admin menu.

[Micemade]

Same / similar issue - referenced above

[m-e-h]

I added a fix for this in pr #4587

Adding the scrollbar to the admin-menu seemed like the cleanest fix and won't even be noticeable to anyone who isn't currently having this problem of not being able to scroll.. It's only applied when the body gets the overflow: hidden (> 600px), so it shouldn't mess with mobile.

I tried to tie the menu in with the body scroll, but just couldn't make it smooth. Also didn't know if we were purposely keeping the scroll off of the body?

I'm just now diving into Gutenberg so I may have missed previous discussions on the layout behavior.
@jasmussen looks like you've spent some time with the layout. Is there a reason we wouldn't want the menu to scroll independently? Is there a better way?

[jasmussen]

Thanks so much for working on this. There are two key issues that we want to make sure doesn't regress:

• Scroll-bleed from the inserter. Try opening the inserter on a very long document, then click the "Blocks" tab and mouse-wheel to the end of the blocks tab. Verify that once you've scrolled to the end of that you don't start scrolling the document below.
• Mobile breakpoints. Verify that this doesn't regress the mobile scrolling behavior compared to master.

From a quick glance, it looks like #4587 seems to both work well, and not introduce any issues with the above two, as far as I can tell.

I'm going to take a look again next week and see if there is a more elegant way to do it, but my gut tells me there isn't, without dropping the individually scrolling main content area (which would re-introduce the scroll bleed). But I'll get back to you, and thank you again!

[m-e-h]

Ahh OK, that makes sense.
Yeah, I'm not seeing #4587 have any affect on scroll bleed or mobile or anything else really except for the admin-menu. Which I'm actually kind of liking with a scroll.

One thing I have noticed with #4587 is that the scrollbar cuts into the width that the menu-items have to work with.
So if a menu-item title is maxing out its 160px , it'll get a letter or two cut off. That's with the overflow-x: hidden I put on the menu-wrap. Otherwise a long title will add a horizontal scroll. Both suck as far as backward compatibility.
I haven't tried to fix that part yet. Maybe something can be done with box-sizing or maybe add a couple extra pixels if we have to.

[jasmussen]

Took another look at the PR, and realized that the reason why there's a horizontal scrollbar, is that the flyout menu has to have space to fit there. Incidentally, our tweaking of overflow breaks that.

Before:

After:

This is a bummer, and means we'll have to take a different approach to addressing this. Thanks again for working on it, though.

[marcusig]

@jasmussen

But given it's an edgecase

I'm not sure it's an edge case. On my laptop with a few plugins installed which add:

• a few menu items
• metaboxes (Woocommerce)

Both the menu bar, the editor's content and the metaboxes get cropped if body { overflow : hidden; }.

I've experimented a bit and found a couple of ways to stop the scrollbleedin' thing, but not sure what's best...

[jasmussen]

Note to self: never use the term edge case 😉 it clearly is an issue that needs fixing, whether edge or not.

Incidentally I submitted a PR earlier today that seems to address it: #4629

[marcusig]

haha :)
Your PR removes the overflow: hidden isn't it?
How about this issue you mentioned?

Scroll-bleed from the inserter. Try opening the inserter on a very long document, then click the "Blocks" tab and mouse-wheel to the end of the blocks tab. Verify that once you've scrolled to the end of that you don't start scrolling the document below.

[jasmussen]

Yep, that's the thing, when the menu needs to scroll, there is a little scroll bleed. When it doesn't, there's no scroll bleed. It's not an ideal fix, and we'll probably want to test thoroughly on metabox heavy configs, but I can't think of another fix that doesn't involve killing the flyout menu.

[marcusig]

I fiddled a bit in the inspector and found a way to stop the scrollbleed with css, and looked at a JS solution as well.
The JS idea: https://jsfiddle.net/0o2y3uw9/
With CSS, if you leave the overflow: hidden on the body and add
#wpwrap { overflow: auto; height: 100%; }
It sort of moves a few things around which would have to be fixed as well.
One of the cons is that the scrollbar for #wpwrap is hidden (the sidebar sits on top), which can be an accessibility issue (yes, some people actually click and drag the scrollbar).

[m-e-h]

Another JS approach would be to toggle a body class when the inserter is open and hide the overflow only while open.

body.inserter--is-visible {
    overflow: hidden;
}

[marcusig]

Could work, but there might be some movement when changing the overflow (showing and hiding the body scrollbar)

[jasmussen]

I fiddled a bit in the inspector and found a way to stop the scrollbleed with css, and looked at a JS solution as well.

Appreciate your help. I've fiddled myself many times:

• https://codepen.io/joen/pen/wGbBoe
• https://codepen.io/joen/pen/Kzjgqy
• https://codepen.io/joen/pen/dMEyjr
• https://codepen.io/joen/pen/wGLjWG
• https://codepen.io/joen/pen/wGONLB

But each of those come with their own tradeoffs, and none of them fit the wp-admin and its legacy code very well. The same with hiding the scrollbar, it causes that page-jog.

As such, I honestly feel like what we have now, with some scroll bleed in the case of long admin menus, is the most acceptable of the various tradeoffs.

I also don't see any issues with the metabox implementation. This feels issue, to me, appears isolated to the left hand navigation pane. Here's a GIF of the overflow-removing PR:

I acknowledge it's not ideal to see the two scrollbars on the right, on short viewports, but it feels like it is the least disruptive patch, and works reasonably well. Also remember that on mobile we're addressing this in an entirely different way.

[marcusig]

Fair enough. It's also probably the most reasonable and clean code.
Off topic, how do you make those GIF screenshots?

[jasmussen]

Off topic, how do you make those GIF screenshots?

For when I need to make long GIFs that aren't insanely huge in filesize (still big, but not crazy), I use Licecap. It uses high compression and low framerates to keep the filesizes down, at the expense of a little choppiness, and light grays disappearing.

When I need to do more high quality GIFs, I used to use Giphy (Mac app store). But now I just screen-record using Quicktime, then open the .mov file in GIF Brewery to convert it to GIF. Finally I run the GIF through ImageOptim to slim down the filesize as much as possible.

[marcusig]

Thanks. It's quite practical to illustrate all this trials and tests.

[jasmussen]

It's very practical. It is a little frustrating that GIF is still the best format for this, since it's so old and impractical. But it's just works everywhere, so I find it still the best way to convey little interactions.

[mikestopcontinues]

What about padding the bottom of the gutenberg editor equal to the admin-menu overflow? Then we'd at least see the bottom of the doc.

[mikestopcontinues]

Actually, is there anything wrong with using fixed positioning for .edit-post-layout__content? Basically, treating it the same as .edit-post-sidebar.