In windowed notebook cells are sometimes rendered out of order

[krassowski]

Description

In windowed notebook cells are sometimes rendered out of order. The order of navigation is thus broken in cells, affects both edge navigation and command mode navigation with arrows. Dragging the affected cells does not change their position.

It looks like a problem with the soft hiding of cells; it looks like a soft-hidden cell stuck around, but maybe this is just a symptom of another problem. Cutting and pasting the affected cell solves the problem.

It is likely related to #15286

Reproduce

I don't know yet but it only happens in long notebooks with full windowing mode enabled. It likely involves scrolling the cell in/out view and possibly some edge cases on modifications

Expected behavior

Cells are rendered in correct order.

Context

• Browser and version: Chrome
• JupyterLab version: 4.1.0b0

[JasonWeill]

@krassowski Just to be sure, do you see this behavior in 4.0.x?

[krassowski]

No, it is 4.1.0b0 specific. As mentioned, likely related to #15286.

[DenisaCG]

I'm currently looking into this issue and will keep you posted on the progress. Feel free to jump in if you have any insights or suggestions. Thanks!

[DenisaCG]

I'm having some trouble reproducing the issue. So far I've tired running notebooks of around 200-300 cells and navigating the cells in both edge or command mode using the arrows, but the rendering order of the cells doesn't seem to change. I've also tried selecting cells or their outputs and moving them in and out of view, same results. In all cases, I have change the settings to full windowing mode, and I am using version 4.1.0b0.

Is there anything more you have done or noticed when encountering this issue? @krassowski

[krassowski]

I will try to reproduce again tomorrow morning. I suspect a combination of cutting/pasting cells or maybe changing their types when the active cell is out of view could be the key.

[krassowski]

I put quite some effort into reproducing it but I could not find any sequence to reproduce it in a clean environment (but I had seen it a few times since reporting it initially in my work environment which has a number of extensions and often complex workspaces making my computer slow down significantly).

[krassowski]

This is how the DOM looks like when it happens:

Notice two code cells with 262 index with a markdown cell with index 261 in between

[krassowski]

We discussed this on the weekly JuypterLab call today: we will still attempt to fix it before the final release, but it is not deemed blocking because it happens in the windowing mode which is not used by default; instead we will add a recommendation in the release notes for users who use the full windowing mode to either postpone upgrading to 4.1 or help with testing that mode in the new version (thanks @jtpio for the suggestion!)

[JasonWeill]

Closing per #16013.