Output_notebook() issue in Jupyterlab

I’m developing a little gui, and am having the issue described below. I’m not convinced this is a bug yet, so I’m putting it on community support. Happy to move it over to github if it turns out there’s a bug.

Issue

show(bkapp,notebook_url=notebook_url) does not display the app bkapp in Jupyterlab
(note that notebook_url is correctly chosen to match the url and port.)

This happens when output_notebook() has been called in advance.
However, calling

import holoviews as hv 
hv.extension('bokeh')

enables the call to show to work. Calling output_notebook after hv.extension will reintroduce the problem.

Example

This failure occures on the on the sample notebook notebook_embed.ipynb.

Installation stats

> jupyter labextension list
JupyterLab v2.2.4
Known labextensions:
   app dir: ~\Miniconda3\envs\py38\share\jupyter\lab
        @bokeh/jupyter_bokeh v2.0.3 enabled  ok
        @jupyter-widgets/jupyterlab-manager v2.0.0 enabled  ok
        @pyviz/jupyterlab_pyviz v1.0.4 enabled  ok
        jupyterlab-jupytext v1.2.1 enabled  ok

running %watermark and %watermark -iv on the linked notebook (with holoviews loaded) gives

CPython 3.8.5
IPython 7.17.0

compiler   : MSC v.1916 64 bit (AMD64)
system     : Windows
release    : 10
machine    : AMD64
processor  : Intel64 Family 6 Model 158 Stepping 13, GenuineIntel
CPU cores  : 12
interpreter: 64bit
yaml      5.3.1
holoviews 1.13.3

Thanks!
-Steve

I can’t repro any problems on OSX with Bokeh 2.1.1 and either Jupyterlab 2.0.0 or 2.2.4. Can you try things on different platforms/machines to see if it is something specific to your current local system?

cc @Philipp_Rudiger @mateusz in case anything here sounds familiar.

Thanks for the quick reply, Bryan.
Here’s the solution:

from bokeh.resources import INLINE
output_notebook(resources=INLINE)

This is required on (my organization-managed) Chrome 84.0.4147.125 on Windows 10
The evidence was in the javascript console showing

Access to script at 'https://cdn.bokeh.org/bokeh/release/bokeh-widgets-2.1.1.min.js' 
from origin 'http://localhost:8888' has been blocked by CORS policy: 
No 'Access-Control-Allow-Origin' header is present on the requested resource.

I could not fix it with any variation of trying to load the script directly in html with the crossorigin keyword.
A little googling indicates that Chrome is cracking down on cross-origin requests, so this problem may become more widespread.

Fortunately, there is no problem in the latest Firefox.

After finding the problem, I realized that running output_notebook had stalled on Loading BokehJS ... rather than showing BokehJS 2.1.1 successfully loaded, so the bug was not silent within the notebook, although I failed to recognize its import. Interestingly, the few non-app plots I tried while debugging had no-issue.

Best,
Steve

@Steve_Maxwell I wish I knew how to fix Chrome’s malfunction here, I really do. We 100% do set the access control header in HTTPS requests:

(211conda) ❯ curl -H "Access-Control-Request-Method: GET" -H "Origin: http://example.com" -I "https://cdn.bokeh.org/bokeh/release/bokeh-widgets-2.1.1.min.js"
HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Length: 253482
Connection: keep-alive
Date: Thu, 13 Aug 2020 03:41:35 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Last-Modified: Mon, 22 Jun 2020 21:26:08 GMT
ETag: "ec361983070aa5637a20e4c431103383"
Cache-Control: max-age=31536000
x-amz-version-id: DOOeQR8oOelJVYEJrvKyRwNUnw6cczSW
Accept-Ranges: bytes
Server: AmazonS3
Vary: Accept-Encoding,Origin,Access-Control-Request-Headers,Access-Control-Request-Method
X-Cache: Miss from cloudfront
Via: 1.1 adc2002956acc4d61bfbf3b973fdf247.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: SEA19-C1
X-Amz-Cf-Id: eQSK_fraylEjRUNaGD-fIWmd3ONDPj_aWT3AEKswtBWG0NbgauFp0g==

Evidently the header is not returned on HTTP requests, but Bokeh itself will never generate any HTTP requests. A fuller discussion (please, chime in if you have any additional info that is not there) can be found in this issue: [BUG] Potential Chrome CORS problem with local output · Issue #9773 · bokeh/bokeh · GitHub

Thanks again, @Bryan . This is such a weird malfunction!

Well if you go down the rabbit hole it seems there is an ambiguity in the spec wrt to caching and origin headers. You could/should also try clearing cache, force reloading, etc.

Clearing the cache worked temporarily. Which I guess is a datapoint

This is enough outside of my knowledge that the entrance to the rabbit hole is…full of dirt and requires much digging (which I started to do…)!