Notebook: Save causes scroll jump

[ellisonbg]

In master, saving a notebook (or autosaving) causes the notebooks div to scroll jump. This may also be in the 4.x series.

[gnestor]

@ellisonbg I can't reproduce this. My steps:

1. Pull master
2. npm run build:watch
3. jupyter notebook
4. Open a notebook
5. Scroll to middle of notebook
6. "Save and Checkpoint"

[dsblank]

I've seen this behavior this week, using the current release (not master). But I only see it in one situation: when I am using a lower-res projector. I never see it on my laptop nor desktop. I'm not sure of the exact dimensions nor zoom of the browser (Chrome on Arch Linux). But I can look at details next time I see it jump.

[gnestor]

@dsblank Does it jump down and back up again about 1s later? If so, this is probably the save/checkpoint notification. I observe this behavior in viewports less than 1000px wide.

[gnestor]

@ellisonbg @dsblank Any news on this one?

[dsblank]

@gnestor I believe that you are correct: what I am experiencing is a narrow screen combined with some long text in the save notification. BTW, sometimes if the browser time is different from the server time, you can end up with a message stating "in about a second", which may take up valuable screen space.

[gnestor]

I think the only solution is to make the notification area CSS position: absolute on narrow viewports which would always take up a dedicated space, regardless of whether a notification is displayed (side note: on master the "Trusted" notification is always displayed).

[gnestor]

Here is an example of save/checkpoint notification on a medium-width viewport:

[gnestor]

I'm going to close this for now. Re-open if the issue comes up again.

[ryan-feeley]

I'm seeing this same issue when viewing notebooks side-by-side on my laptop. There are two components.

1) The save checkpoint moves the content down the expected amount to due to the notification height, this is unfortunate, and could perhaps be addressed by a UI change, but not a big issue since the vertical jump is relatively small.

2) The other is that the vertical spacing in multi-line print output for numpy arrays is momentarily increased while the checkpoint notification is displayed. This is a bigger issue, since the vertical jump can be arbitrarily large depending on the notebook content.

I'm using the latest Anaconda distribution with

(base) C:\Users\ryan>jupyter --version
4.4.0

(base) C:\Users\ryan>jupyter notebook --version
5.0.0

[Note, there is minimal nondefault theming in this screenshot, the issue also happens with the defaults.]

[takluyver]

That looks like something is making the available width narrower, so the lines wrap around. Can you see what might be doing that?

[ryan-feeley]

@takluyver

Interesting, yes, the available width is changing. It appears to be related to me having changed the default Windows taskbar location to put it on the right side. If you look at the image above, there appear to be two vertical scrollbars on the right side of each notebook. The inner one is useful, and the outer one appears to be a UI bug that is triggered by putting the windows taskbar on the right.

The left window always has two vertical scrollbars (so seems to have a display bug). The right window normally has only one, but a second one appears during the checkpoint save operation.

If I swap the left and right windows, so I'm editing a notebook in the left size, then there are always two scrollbars, so this additional vertical jump during checkpoint save (my # 2 above), does not occur.

If I move the taskbar location to the bottom of the screen, then both windows have only a single scrollbar (so normal expected behavior), and again my # 2 above does not occur.

[ryan-feeley]

If I start with a very narrow window that is displaying the notebook, and horizontally drag the window wider, the 2nd scrollbar repeatedly appears and disappears, so it appears to be present only at discrete widths.

All the above has occurred with the Windows 10 Edge browser. I am unable to reproduce this 2nd scrollbar with the latest firefox version.

[takluyver]

Ah, OK. I don't think we've ever really aimed to support IE/Edge, though we know it mostly works in recent enough versions.