navigating to localhost:5000 shows " Loading OctoPrint's UI, please wait..." forever.
From Chrome's console log I think this is the root-cause:
Refused to execute script from 'http://localhost:5000/static/webassets/packed_libs.js?3339d949' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.
(index):1 Refused to execute script from 'http://localhost:5000/static/webassets/packed_client.js?92e73cbf' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.
(index):1 Refused to execute script from 'http://localhost:5000/static/webassets/packed_core.js?a90e3d70' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.
(index):6482 Uncaught ReferenceError: $ is not defined
at (index):6482
Background...
I installed Python 3.8 for Windows 10
I installed OctoPrint 1.4.0rc1 to c:\octoprint using the setting-up-octoprint-on-windows guide.
I upgraded to 1.4.0rc2 on Dec 2
I tried using chrome and edge browsers.
I expected to see the standard OctoPrint UI (or on the very first run, see the setup wizard)
I see "Loading OctoPrint's UI, please wait..."
And no other indication of anything happening
Yes.
1.4.0rc1 and 1.4.0rc2
Windows 10 Pro 1809
2019-12-02 13:55:02,752 - octoprint.environment - INFO - Detected environment is Python 3.8.0 under Windows (win32). Details:
| hardware:
| cores: 8
| freq: 2401.0
| ram: 17057427456
| os:
| id: windows
| platform: win32
| python:
| pip: 19.3.1
| version: 3.8.0
| virtualenv: c:\octoprint\venv
Currently, the Windows machine is not physically connected to a printer.
Chrome Version 78.0.3904.108 (Official Build) (64-bit)
Microsoft Edge 44.17763.831.0
https://gist.github.com/elfelton/7c24f0d6b1834c538206fb997e759309#file-octoprint-log
Refused to execute script from 'http://localhost:5000/static/webassets/packed_libs.js?3339d949' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.
(index):1 Refused to execute script from 'http://localhost:5000/static/webassets/packed_client.js?92e73cbf' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.
(index):1 Refused to execute script from 'http://localhost:5000/static/webassets/packed_core.js?a90e3d70' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.
(index):6530 Uncaught ReferenceError: $ is not defined
at (index):6530
https://user-images.githubusercontent.com/8985461/70002202-35f7ed00-1557-11ea-8885-56f2e896d17e.png
I have read the FAQ.
Hello, I am able to get OctoPrint 1.3.12 and Python 2.7 running on the same machine.
The octoprint.log will show both 1.4.0 and 1.3.12 information over the last several days. The 1.3.12 UI starts up as expected, I am only encountering this issue with 1.4.0
Hi @elfelton,
It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).
If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.
Please do not abuse the bug tracker as a support forum - that can be found at discourse.octoprint.org. Go there for any kind of issues with network connectivity, webcam functionality, printer detection or any other kind of such support requests or general questions.
Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.
I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2019-12-17 00:10 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!
Best regards,
~ Your friendly GitIssueBot
PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.
I'm not sure what information I'm missing that the GitIssueBot is flagging. I provided everything I can given the current situation. If a human has any specific questions I'm happy to answer them.
I found this issue and resolution elsewhere
https://github.com/jupyterlab/jupyterlab/issues/6098
I updated my Registry and the UI now loads in Chrome.
I don't know if the proper thing to do is close this OctoPrint issue or to document the behavior and the solution. Or have the OctoPrint installer check the registry and make the appropriate changes.
I've added a bit of protection against this causing issues by enforcing the correct MIME types for .js and .css files on the built-in webserver, regardless of whether the registry has broken values configured or not.
Still interesting that this seems to be widespread enough that there's a whole number of tickets on various projects out there. I wonder what kind of software is behind these messed up registries. My own was clean, I borked it intentionally to test the above commit's effect how ever and can confirm it worked.
1.4.0rc3 has just been released
Most helpful comment
I've added a bit of protection against this causing issues by enforcing the correct MIME types for .js and .css files on the built-in webserver, regardless of whether the registry has broken values configured or not.
Still interesting that this seems to be widespread enough that there's a whole number of tickets on various projects out there. I wonder what kind of software is behind these messed up registries. My own was clean, I borked it intentionally to test the above commit's effect how ever and can confirm it worked.