Scroll Jumps and jarring effect with full windowing mode

[singharpit94]

I am using jupyterlab 4.2.0 and observed that the full windowing mode which is enabled by default causes the native scrollbar jumping and causing jarring effects, Attached a gif for more clarity about the issue.

Here is the code I used to create tabular tables in all the cells.

import datetime as dt
import numpy as np
import pandas as pd
import panel as pn

np.random.seed(7)
pn.extension('tabulator')

df = pd.DataFrame({
    'int': [1, 2, 3],
    'float': [3.14, 6.28, 9.42],
    'str': ['A', 'B', 'C'],
    'bool': [True, False, True],
    'date': [dt.date(2019, 1, 1), dt.date(2020, 1, 1), dt.date(2020, 1, 10)],
    'datetime': [dt.datetime(2019, 1, 1, 10), dt.datetime(2020, 1, 1, 12), dt.datetime(2020, 1, 10, 13)]
}, index=[1, 2, 3])

df_widget = pn.widgets.Tabulator(df, buttons={'Print': "<i class='fa fa-print'></i>"})
df_widget

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[krassowski]

I can reproduce this with the tabulator panel code. I see some jarring with the windowing mode disabled too but it is of different kind. When windowing is enabled I see that the panel tabulator re-renders each time the cell enters the view.

The panel uses setInterval trying to detect if the dependencies are available every 25ms for 200 times (5 seconds total). It appears that if a cell was run when out of view, and user scrolls the notebook so that the cell is in the rendering range (but not necessarily visible) within 5 seconds, panel will populate the output and move the scrollbar slightly, but this may not be the major culprit.

The major issue might instead be that the outputs are re-rendered when cell output visibility changes by panel tabulator; this means that it competes with JupyterLab in its ability to optimize out the widgets (outputs) which are not visible to user. This cannot be reproduced with simple JS rendering in outputs. The re-rendering can be also seen when switching tabs (independent of windowing mode):

It calls redrawTable, which to make things worse trashes the layout:

When running the cell with tabulator I also see that the output jumps a long way for a split second before the table renders properly; there is some visible layout trashing too:

If the panel extension re-renders the output this way each time the cell enters the view, it will lead to annoying jumping of the scrollbar indeed.

It looks like the jump in cell height starts after adjust_table_size panel function is called and stops in consequence of style_redraw panel function being called:

[krassowski]

On JupyterLab side, we need to make better job to respond to such jumping height of the output. It is quite tricky to get this right.

We should investigate whether using content-visibility: hidden for windowing could solve this problem.

[singharpit94]

Thanks @krassowski for taking a look here, the actual problem also exists with our inhouse extensions which outputs rich outputs (React based widgets) which does not have the visibility based logic which in general causes issues even without windowing like in tab switching and all as you have mentioned.

I would request we should gather more feedback and test more the native scrollbar with the windowing mode as I think this issue might not be confined to limited cases.

[krassowski]

Looking a bit more into why this might be the case for a React component and not only panel custom logic.

For the case of running the cell (in the panel case) there is a logic which is invoked based on the browser events, like CSS stylesheet getting loaded, rather than on explicit visibility check:

For the case of scrolling, there is a function which runs every quarter of a second comparing the height of the cell output and triggering the slow update which causes jitter. I think that because scrolling the windowed notebook in changes heights of outputs from 0 to their actual height this is causing the problematic rerender which causes jitter:

this._parent_observer = setInterval((()=>{
      const t = this.el.offsetParent;
      this._offset_parent != t && (this._offset_parent = t,
      null != t && (this.compute_viewport(),
      this.invalidate_layout()))
  }
  ), 250));

Does your React widget has any interval, any resize observer, or any callback to other browser events such as styles being mounted?

[singharpit94]

Does your React widget has any interval, any resize observer, or any callback to other browser events such as styles being mounted?

Yes, we actually use all the above and it just might be the case that we are affected by them.

It will be hard to share an exact reproducer but one way would be to create a widget on top of https://github.com/schrodinger/fixed-data-table-2 and maybe have some browser observers attached to it, it can help create a reproducer

[burnpanck]

Could this be the same issue as #15968 ? In that case, there is no tabulator interface involved though...

[krassowski]

I don't think so because this issue is specific to windowing mode. The issue in #15968 seems to be in the scrolling logic shared between all the modes.