As per issue #3335, we want all js tests migrated to selenium. This change migrates the test of buffered execution requests.
Test Plan:
py.test -v notebook/tests/selenium/test_buffering.py
- use %r instead of %s to handle quoting more succintly
- add a finally block to ensure browser state is transitioned from iframe back to default content
As per issue #3335, we want all js tests migrated to selenium. This change migrates and extends the svg isolation test (extended to include slightly more thorough validation of expected isolation behavior).
Test Plan:
py.test -v notebook/tests/selenium/test_display_isolation.py
Migrates a single js test (testing image display functionality) to selenium as per issue #3335.
Test Plan:
py.test -v notebook/tests/selenium/test_display_image.py
Currently the default URL message given on the console on startup is:
---
Copy/paste this URL into your browser when you connect for the first time,
to login with a token:
http://(myip.com or 127.0.0.1):8888/?token=8fdc8 ...
---
This will always need editing to use. Replace with one host IP (e.g. 'myip.com')
option and one local ip (127.0.0.1) option to make it copy/pastable again.
Currently the default URL message given on the console on startup is:
---
Copy/paste this URL into your browser when you connect for the first time,
to login with a token:
http://(myip.com or 127.0.0.1):8888/?token=8fdc8 ...
---
This will always need editing to use. Replace with host IP (e.g. 'myip.com')
to make it copy/pastable again.
This allows slower contents managers to not block the event loop by allowing
more of their API to return futures.
Other usages of contents manager functions are already wrapped in maybe_future,
including a use of `file_exists` in contents/handlers.py
Recently I needed to troubleshoot kernel responses and found it helpful
to distinguish status types (busy vs. idle) - thought others might find
it useful as well.
Entries that previously appeared as...
```
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_input
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: display_data
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_result
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
```
will now appear as...
```
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (idle)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (busy)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (idle)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (busy)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_input
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: display_data
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_result
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (idle)
```
Then split the file into two files, one containing the metrics themselves, the other containing any function that have something to do with prometheus.
Finally, Added new metrics into the prometheus.metrics file that represent the number of running terminals and added the functionality for that metric to be recorded in the terminal.api_handlers file.
It's still (IMHO) unclear how the adaptation goes. Like does "adapting
to protocol X.Y.Z." mean the end-result is X.Y.Z or what you
got is X.Y.Z and it's X.Y.W after adaptation.
