8000 webAgg example broken - maybe mpl.js broken? · Issue #19129 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]
Skip to content
8000

webAgg example broken - maybe mpl.js broken? #19129

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ianhi opened this issue Dec 16, 2020 · 8 comments
Closed

webAgg example broken - maybe mpl.js broken? #19129

ianhi opened this issue Dec 16, 2020 · 8 comments
Labels
GUI: webagg
Milestone
v3.3.4

Comments

@ianhi
Copy link
Contributor
ianhi commented Dec 16, 2020 •
edited
Loading

Bug report

Extracting the extra bug discovered in #19116 (comment)

Bug summary
The code in https://matplotlib.org/devdocs/gallery/user_interfaces/embedding_webagg_sgskip.html does not display anything in the browser when running master matplotlib (27aaf0c)

Code for reproduction

Actual outcome

No plot + this DOM exception in the JS console:

Uncaught DOMException: An attempt was made to use an object that is not, or is no longer, usable mpl.js:394
    send_message http://127.0.0.1:8080/mpl.js:394
    _init_canvas http://127.0.0.1:8080/mpl.js:161
    figure http://127.0.0.1:8080/mpl.js:55
    <anonymous> http://127.0.0.1:8080/:40

Expected outcome
A working interactive plot shows up

Matplotlib version

  • Operating system: Ubuntu 20.04
  • Matplotlib version: 27aaf0c
  • Matplotlib backend (print(matplotlib.get_backend())): webAgg
  • Python version: 3.9.0
  • Browser: Firefox 83.0

Installed python from conda-forge:

Python 3.9.0 | packaged by conda-forge | (default, Oct 14 2020, 22:59:50) 
[GCC 7.5.0] on linux
@ianhi ianhi mentioned this issue Dec 16, 2020
Open
@QuLogic
Copy link
Member
QuLogic commented Dec 16, 2020

This is also broken as of v3.3.3, but I'm sure I tested this then due to backporting fixes for older Firefox. I wonder if this was a change in Firefox that broke it.

@tacaswell
Copy link
Member

In chrome derivative on 3.3.3 I get a slightly better error:


mpl.js:390 Uncaught DOMException: Failed to execute 'send' on 'WebSocket': Still in CONNECTING state.
    at mpl.figure.send_message (http://localhost:8080/mpl.js:390:13)
    at mpl.figure._init_canvas (http://localhost:8080/mpl.js:161:13)
    at new mpl.figure (http://localhost:8080/mpl.js:55:10)
    at HTMLDocument.<anonymous> (http://localhost:8080/:40:21)

I also manually tested this in prep of 3.3.3 . Could the problem be on the other side and someting changed in tornado's websockets?

@QuLogic
Copy link
Member
QuLogic commented Dec 16, 2020

This bisects to #18361, which sends the pixel ratio message earlier (in _init_canvas); I suppose leaving it to the ws.onopen might be fine, but needs testing?

@tacaswell
Copy link
Member

🐑

@tacaswell
Copy link
Member

I did just verify that nbagg still works on v3.3.3 so that is good at least. Presumably we go through a slightly different song/dance to stand the js side figure up in the two cases?

@QuLogic
Copy link
Member
QuLogic commented Dec 16, 2020

Yes, nbagg uses a proxy to a WebSocket from ipykernel, which I assume is already stood up before we get it.

@QuLogic QuLogic added this to the v3.3.4 milestone Dec 17, 2020
@aathan
Copy link
aathan commented Jan 24, 2021 •
edited
Loading

I (independently) found and fixed this bug in the onopen() manner suggested above, so the fix is corroborated. This was in matplotlib 3.3.3 vs recent Firefox. Just to be explicitly clear, what I am saying is: Ttriggering the call to mpl.figure() (in all_figures*.html or single_figure*.html) via websocket.onopen() works.

(see https://discourse.matplotlib.org/t/webagg-backend-js-bug-websocket-not-ready/21796)

Looking at 30a900f which closed this problem it seems the fix was to not send pixelratio. However, that would not seem to me to address the root cause. The fact is that neither mpl.figure(), nor anything else, should use the websocket before it is open. As written, the possibility remains open that any future changes to mpl.figure() initialization will cause the issue to happen again.

I believe the correct solution is to not initialize mpl.figure() until the socket is in fact ready -- or otherwise cause mpl.figure() to refrain from socket operations until we're sure it is open. The link above shows how I avoided the issue by calling mpl.figure() (in all_figures*.html) from websocket.onopen(). However, it did not occur to me that I may then have overriden the original onopen() behavior of that websocket. Possibly I need to also call the prior onopen()?

@QuLogic
Copy link
Member
QuLogic commented Jan 28, 2021

I suggest you open a pull request so we can review the change better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
GUI: webagg
Projects
None yet
Milestone
v3.3.4
Development

No branches or pull requests
5 participants
@tacaswell @QuLogic @story645 @ianhi @aathan
0