Despite it not being the cause of the problem, the changes I outlined in #13 for the viewer might still be a good thing to have:
Instead of the server pushing a giant JSON blob of everything to the client at the start (the opinions JS list), I think probably what needs to happen is a XHR on CSD change (in, say, set_csd).
After the client JS decides it needs to change which CSD is being displayed, It would need to do something like this:
In set_csd main loop:
1.1. client disables all/most of the UI elements
1.2. location.assign for new_csd
1.3. XHR sent to server indicating that it wants to display CSD=new_csd
1.4. Set iframe src to rendered notebook for new_csd
1.5. Done
The server would respond with JSON containing:
2.1. new csd_to_display (which may not be new_csd, because clients can't be trusted)
2.2. the targets of the six navigational buttons
2.3. the user's current opinion for csd_to_display
2.4. the opinion count for csd_to_display
2.5. probably the entirety of csd_list, since the server has it on hand and it may have changed
Then, in the XHR callback, the client would finish up with:
3.1. If csd_to_display != new_csd:
3.1.1. do another location.assign
3.1.2. Set iframe src to rendered notebook for csd_to_display
3.2. Update script globals with data from server
3.3. Update and enable UI elements with data from globals
The templating itself wouldn't change much, except for getting rid of the JSONified opinions list.
This trades login-in lag for csd-switching lag with the assumption that the second will be lower/less noticeable than the first.
In 1.4, we set the iframe src early, even though it may change later, to give the user something to distract themselves with while their client is waiting for the UI data.
If the XHR fails, then the user is going to be left with an almost entirely inactive UI. Probably we'd keep the logout button enabled. We could also maybe keep the CSD selection text box enabled. The point of the location.assign in 1.2 is so they can do a hard-refresh in their browser to try to recover.
The csd_list from the server in 2.5 solves the problem of a logged-in user's session being currently unable to pick up new days when they arrive on bao.
This would also simplify the implementation of #12 since the user's chosen N could be sent in the XHR to the server to modify navigation.
Despite it not being the cause of the problem, the changes I outlined in #13 for the viewer might still be a good thing to have: