I was trying to get some interactive matplotlib plots to work in a Python notebook in SWAN using
%matplotlib notebook. Plotting after enabling notebook mode yields the usual interactive panel and the buttons are all functional, but the cursor position that the interactive features read doesn’t match with the actual cursor position on the plot (seems to be shifted by the distance scrolled past the top of the page). e.g. after scrolling slightly down the page, when drawing a zoom box, it will be drawn over the plot at a position far below the cursor
The above description is with Chrome, cursor interactivity seems to be completely off in Firefox, though maybe due to the same problem.
Simple code that reproduces the bug:
import matplotlib.pyplot as plt
I recommend checking out the widget backend, rather than the older “notebook” backend. That particular backend comes from the ipympl project (GitHub - matplotlib/ipympl: Matplotlib Jupyter Integration) and is better aligned with ipywidgets.
I just double checked, and found it worked well on SWAN with LCG99 (enabled with
Thanks for the suggestion, I wasn’t aware of that backend and it’s much nicer than
%matplotlib notebook. Unfortunately I still have the same problem using it.
In order for the bug to occur I need to be scrolled down within the browser window. To reproduce that aspect I guess you can make the window small enough that you have to scroll to view the plot or just add a bunch of empty cells. If you do this, do you still not experience the issue?
I just tried with LCG 99 and widget as Phil did and I don’t see the behaviour you describe (the reported cursor position coincides with the actual position). This is with Chromium.
Is this something you can reproduce outside of SWAN?
EDIT: I now read you don’t have this behaviour in a normal notebook. It’s definitely not something we are aware as a bug and it’s weird that we can’t reproduce consistently.
Just one more thing: I now tried
%matplotlib notebook and I do see some strange behaviour with the cursor, e.g. when I create the plot on a cell and I add cells above it a posteriori - the lower coordinates are not reported anymore when I move the cursor to them. I don’t see this with widget, though.
Hey, yes this is the exact behavior I experience, but I also get it with widget.
I should note that it seems to require that there actually be a scroll bar on the page. Zooming in and scrolling down doesn’t seem to reproduce the bug, but reducing window size or adding cells to allow scrolling (and then scrolling down) does.
I’m not familiar with how the front-end of SWAN works, but does it do anything differently from a regular jupyter notebook window that may alter the communicated window height/width and/or X/Y position? It seems to me like this info is what is being communicated incorrectly when scrolled down.
Yes, I saw it now by adding several cells at the top after drawing.
@dalvesde do we do anything in the frontend that could cause this behavior?
The only thing different, I believe, is that we fix the toolbar when scrolling. Maybe that affects… Need to try and see.
I think this is related to this problem that I reported to the SPI team
they told me that several users have the same issue, it is our case in SWAN too, several users are reporting this.
the last know stack working with zoom is LCG_97a.
@ozapatam , all,
This seems caused by our template. If I revert to the upstream one, it works (they have a fixed div for the notebook content, which we do not).
Are those users that reported SWAN users only or others as well?
At the moment I’m not sure how to fix it without doing major, lengthy, changes… I guess we will have to consider it a known bug, without a planned fix, and we will wait for the Lab integration in SWAN as an alternative.
Thanks @dalvesde for testing this, Very interesting,
Yes, this is the another user reporting it, https://sft.its.cern.ch/jira/browse/SPI-1808
it is for SWAN too.
We’ve found a bug with the version of the extension we have installed in CVMFS (which interferes with the SWAN template). We will ask the LCG librarians to update to the latest one, which should solve this issue. Will give an update here when it becomes available so that it can be tested.
The problem is still present on the Bleeding Edge software stack, which I think is using the nightly of the LCG. Therefore, I was wondering if you could check if your update was integrated to LCG or maybe it is not working ?
Do you use
because the one that works is the first one.
I was indeed using notebook. And it also works for me using the widget instead.
Thank You @mato