document is null error, prevents notebook saving

[parente]

There appears to be a weird timing bug with showing the logo for the current kernel spec and with the DOM being ready. I typically see this when accessing a remote notebook server where the connection is a bit slow.

When it happens, the problem is undetectable (short of watching the JS console) until I go to save the notebook. Then I get the dreaded:

at which point I have to run Jupyter.notebook._fully_loaded = true to save my work (if I know this cheat code) or cuss because I can't save whatever I've typed into the notebook since loading it (if I don't know the cheat code).

The problem seems to be coming from here:

notebook/notebook/static/notebook/js/kernelselector.js

Line 135 in fe1490f

logo_img.show();

I don't mind taking a crack at a fix since it's really annoying when it bites. But I need a bit of guidance. Is there or should there be a DOM-ready guard somewhere earlier in the call stack before this method gets invoked, or does this method need to guard against DOM-readiness itself before calling img.show or hide? What about other places in the code?

[rgbkrk]

I feel like I'm running into this too yet it's intermittently affecting my users.

[takluyver]

Could someone who knows about the notebook JS give @parente a hand getting this fixed? It sounds like it should be pretty simple with the right knowledge.

[minrk]

I suspect it's related to the fact that any errors in handlers for an event are raised in the .trigger call. For instance, in:

        events.one('test_event', function () {
            console.log('triggered');
            undefined_error();
        })
        console.log('triggering');
        events.trigger('test_event');
        console.log('after trigger');

after trigger will never be reached due to the error in the event handler raising in the .trigger() call. So any error in an event handler called during the notebook-loading path can preempt setting the finished-loading flag.