regression with jupyterlab 4.2

[parmentelat]

for a couple days/weeks now, I have noticed a regression in jlab sessions that use this extension

the symptoms are

• cells take needlessly large height
• scrolling up and down triggers odd behaviours, like
  • space between cells increases even further
  • cells move from one row to the next
  • scrolling gets stuck

and this even with notebooks that do not have gridwidth tags at all

I need to

• investigate and confirm my gut feeling that a recent jlab is causing the issue
• bisect to find the actual version that breaks
• find a way to fix the problem

because at first sight what is happening it it rather mysterious

broken jupyter --version

Selected Jupyter core packages...
IPython          : 8.25.0
ipykernel        : 6.29.4
ipywidgets       : 8.1.3
jupyter_client   : 8.6.2
jupyter_core     : 5.7.2
jupyter_server   : 2.14.1
jupyterlab       : 4.2.1
nbclient         : 0.10.0
nbconvert        : 7.16.4
nbformat         : 5.10.4
notebook         : 7.2.0
qtconsole        : 5.5.2
traitlets        : 5.14.3

[parmentelat]

when using either

• jupyterlab 4.0.13
• jupyterlab 4.1.8
  I get the expected behaviour, i.e. this, on the first example notebooks in this repo

[parmentelat]

here's the behaviour obtained on the same notebook with either

• jupyterlab 4.2.0
• jupyterlab 4.2.1
  the whole time we're only scrolling down with the mouse

[krassowski]

Can you go to Notebook settings and change the windowing mode to none from full (default since 4.2) and see what happens? Similarly, on 4.1 if you change to full can you reproduce this? I would suggest reloading JupyterLab after changing this setting.

[parmentelat]

with 4.2.1, if I go to 'none' windowing mode, the issue vanishes

what's the deal with the windowing mode ?

[parmentelat]

and conversely under 4.1.8, moving to 'full` windowing mode triggers the issue

[parmentelat]

is there a way for an extension to act on these settings ?
I mean, is it OK to consider doing so ?

[krassowski]

Yes, jupyterlab-execute-time does so, but it has a setting specific to its use case. Some users may find it annoying if you switch the windowing off but as a short-term solution until you can figure out how to support windowed mode it sounds reasonable to me (provided it is well documented).

[parmentelat]

thanks @krassowski; about this:

until you can figure out how to support windowed mode
I wouldn't know where to start, where is this 'windowing' thing documented ?

[krassowski]

I wouldn't know where to start, where is this 'windowing' thing documented ?

https://jupyterlab.readthedocs.io/en/stable/developer/performance.html#windowed-list

https://jupyterlab.readthedocs.io/en/stable/api/modules/ui_components.WindowedList.html

https://jupyterlab.readthedocs.io/en/stable/api/classes/notebook.NotebookWindowedLayout.html

https://jupyterlab.readthedocs.io/en/stable/api/classes/notebook.NotebookViewModel.html

[parmentelat]

thanks for the pointers

in the meanwhile I'm tempted by the short-term approach (because otherwise the disease will slowly spread to all my students as they upgrade their envs, leading to a mess..)

it feels however that it's not just a matter of changing the windowingMode setting directly - because understandbly my extension won't be allowed to modify the notebook's extension settings, iiuc from reading this
https://discourse.jupyter.org/t/how-do-i-override-settings-using-my-extensions-schemadir-file/8599/2

now, how can I achieve this as an externion developer ?
as opposed to an operator, which the above post only addresses - iiuc again

thanks !

[krassowski]

Does this help?

https://github.com/deshaw/jupyterlab-execute-time/blob/c020582313868db92f1b0bdbae71aeb305b29fc1/src/index.ts#L54-L66

[parmentelat]

yes thanks, I believe this should get me started

just a question though
do I understand correctly that in the linked code, 'enabled' is a setting local to the execute-time extension, and it is not related to the generic 'enabled/disabled' status of an extension, is that right ?
I would have thought that the activate method of the plugin would not even be triggered if the extension is disabled, no ? (in which case a test against 'enabled' would always return true...)