Re-running cells on slides messes up layout

[kmcnaught]

I'm using chrome Version 61.0.3163.100 (Official Build) (64-bit) on Mac OSX, Python 3.6.1 and rise (5.2.0) installed through pip.

I am finding that executing a cell from within the presentation causes the layout to be broken.

non-interactive cells

• Go to slide
• Content is centred
• Edit cell content, ctrl-click to execute
• Content has shifted down
• Select cell and re-execute (without changing anything)
• Content is centred again

interactive cells

Using matplotlib and interact within a cell on a slide:

• Go to slide
• Content is centred
• Edit cell content, ctrl-click to execute
• Content has shifted down
• Select cell and re-execute (without changing anything)
• Content is still misaligned
• Go back a slide
• Go forward again
• Content is centred again

This can be seen in the following video: demo video

and replicated using this notebook: demo notebook

[damianavila]

Thanks for the detailed report! I will investigate the issue as soon as I can.

[jesford]

I can confirm this is still an issue. A quick backward-forward does fix the alignment, so I'm using that for now, but it is annoying if you want to execute cells frequently. Anyway, thanks for all your hard work on RISE, I'm really enjoying using it!

[parmentelat]

the OP is obviously using something really old

I have tried to reproduce with the provided notebook (please next time provide something self-contained with needed imports :-)

In any case with rise 5.6 I can't seem to reproduce - unless I misunderstood the issue that is, which seems unlikely given the video..

my environment for this test :

[rise] ~/git/rise/examples (maint-5.6 *=) $
pip show rise | grep Version
Version: 5.7.0.dev1
[rise] ~/git/rise/examples (maint-5.6 *=) $
jupyter --version
jupyter core     : 4.5.0
jupyter-notebook : 6.0.1
qtconsole        : 4.5.4
ipython          : 7.7.0
ipykernel        : 5.1.2
jupyter client   : 5.3.1
jupyter lab      : not installed
nbconvert        : 5.6.0
ipywidgets       : 7.5.1
nbformat         : 4.4.0
traitlets        : 4.3.2

[parmentelat]

PS. I'm adding this test notebook as examples/issue-370.ipynb in the maint-5.6 branch

[jesford]

Thanks for your quick reply @parmentelat ! I downloaded the example notebook you mentioned above, and I do see the same behavior as the OP, similar to what I see in my own notebooks. Here are the packages in my current environment (I am on an older version of conda unfortunately, but I don't know how that would be related if the packages are all up to date):

(datascience) jes.ford@macbook:~ $ conda list rise
# packages in environment at /anaconda3/envs/datascience:
#
# Name                    Version                   Build  Channel
rise                      5.6.1                    py37_0  
(datascience) jes.ford@macbook:~ $ jupyter --version
jupyter core     : 4.6.3
jupyter-notebook : 6.0.3
qtconsole        : 4.7.4
ipython          : 7.13.0
ipykernel        : 5.1.4
jupyter client   : 6.1.2
jupyter lab      : 2.0.1
nbconvert        : 5.6.1
ipywidgets       : 7.5.1
nbformat         : 5.0.4
traitlets        : 4.3.3
(datascience) jes.ford@macbook:~ $ conda --version
conda 4.6.14

I am using Chrome on a Mac OS 10.14.6. I tried Safari and see the same behavior there. Are there any other tests you would recommend I try? Or other details I can provide?

Thank you very much!

[parmentelat]

turns out I wrote that a little too fast to notice that I'm actually trying with the latest dev release ! which unfortunately was not exposed to pypi yet, so I can't tell you you to try this out.

I'll try to find some time to see how that same notebook behaves for me within a vanilla 5.6.1 version of rise, and/or to publish the dev version, to see if we can make progress on this one

somehow I have a vague feeling that I'm missing the problem entirely, although it was quite clearly described in the first place by @kmcnaught

[jesford]

Maybe try re-executing the same cells multiple times when you do test it again. I am pretty sure the behavior is somewhat intermittent, so the first try may not catch it.

[parmentelat]

Hey; right, I can see it now that you outlined it was intermittent

I believe this behaviour has been around for quite some time; there's some hidden complexity here as the height of elements changes at run-time, and so it feels like the underlying slideshow utility - namely reveal.js - has trouble to cope with that; my gut feeling also is we have kind of race conditions in the asynchronous responses for both jupyter and reveal.js; so in short it's a tricky business that I am not quite sure how to reliably address... I'd like to hear @damianavila's thoughts on the core of that matter

meanwhile, in case it helps, my personal warkaround is to use 'w' twice - only because it is faster than space/shift-space; 'w' toggles overview mode, it's fast to type twice, and that sequence will produce the same healing effect

[damianavila]

Hey; right, I can see it now that you outlined it was intermittent

Mmm... those are usually difficult to figure it out... I need to dig into this to know what could be the source of the problem. In the past this type of errors was related to the interaction of codemirror with Reveal.js and the Notebook stuff.... so a really big mess :wink:. I will try to spend a little bit of time to debug this one soon.

Thanks again for catching this, @jesford! And @parmentelat for digging a little bit into this one as well!