The trouble is, after manually re-installing, the issue isn't there. Even if I have the same troublesome custombackground plugin installed (which still gives me a 404 error), the wizard proceeds as usual. My best guess is that it was some version of one of the python modules that was installed prior to the pinning of various things to a specific version (I haven't started my VM in forever). When the wizard failed to proceed, there were ZERO javascript errors at all in the console that had to do with octoprint (just the plugin, which doesn't seem to interfere with the wizard anyway). It was just as if the buttons weren't connected to anything. No errors, no change in the UI (it didn't say it was either enabled or disabled).
I've been unable to replicate this again at all, which was initially what lead me to believe it was something I'd broken. I've tried rolling back to 1.3.9 again, updating to 1.3.10rc, nothing (and by nothing I mean it works, there's no error).
The "null" entry in the configuration file was what broke the entirety of octoprint, I don't believe that was the cause of this issue though, I now think that is a separate issue caused by perhaps me manually removing a plugin through just deleting the folder.
Neither of my actual printer installs have been started in months, I'm not even sure which version of octoprint they're running anymore (one of them might even be 1.3.7 or 1.3.8). If you want, I can let you at them remotely and you can upgrade to 1.3.10rc yourself to see if either of those do it. I tend to have the same plugins installed there as the VM does.
I know, but the others are still able to reproduce it and could provide information needed to possibly figure this out, yet so far none have. It's highly frustrating, because as you said, it's not reproducible on a clean install, and it also hasn't shown up on any of my 8 update scenarios I tested prior to rolling out the RC, or either of my printers, so in order to be able to fix this I need people to collaborate with me, but so far everyone (apart from you) who's run into this has only gone "it's broken, fix it".
Not sure what's up with this RC to be honest, haven't had these many people in the past running it but not willing to follow basic bug reporting protocol. Actually thinking about making it harder to run RCs after this experience.
So @PythonAteMyPerl was just possible to reproduce something that looks like it is this issue and kindly gave me access to the instance so I could poke around a bit. The issue in his case is that he has webasset bundling disabled (which usually requires a manual config.yaml edit) and that made uBlock Origin block the viewmodel used for the wizard that happens to be called tracking.js - ironically it doesn't do any kind of tracking, it merely makes the wizard functional, so in this case that blocking behaviour is a bit overeager.
In any case - I kinda doubt that there are many people out there that have webasset bundling disabled, so I'm now wondering if maybe other ad blockers out there might be doing a deeper look at the bundled data (which uBlock Origin is happy with) and nuke necessary bits of the UI in the process.
edited to add: what happens when you just click "Finish"
Update on this
Looks like the ad blocker can't be the issue here after all since it would also block the part that is responsible of the "please decide" message on clicking "Finish".
So... logs & console outputs please instead of attitude. Still no reproduction possible over here or apparently for 660+ other people that already fired up 1.3.10rc1 and opted in.
Still waiting for this @mkhemi & @kd7eir. Cannot look into this without that info and possible more. Still no reproduction and now at 870+ instances running an RC with opted-in tracking.
@redangel1984 Can you reliably reproduce this? As in, is it still broken? If so, is there any chance I could somehow take a look at this via some form of screen sharing or an SSH tunnel?
So, at least the issue as observed by @redangel1984 wasn't actually remotely caused by the tracking plugin but rather a third party plugin "Roomtemp" that blocked an important internal thread during server startup, by that prevented these components from starting up and as an end result causing the whole HTTP communication to lock up. That caused not being able to send any kind of commands from the UI to the backend, like a decision on a wizard dialog.
I've hardened the server against problems like this, will blacklist the plugin in question (the only reason it's not causing such obvious breakage right now in the field is pure coincidence) and also report this on the plugin's tracker.
What I don't know is if this (or something like this caused by a different third party plugin) was also the underlying cause for other observations of this problem as mentioned here - for that I still lack the necessary information to analyse this.
:
