Hi there, again
The panel to show up normally
Look at this screen cap, more useful than a long text
octoprint2.zip
Note : I think the problem appeared on a recent commit (not older than a month) because all was fine when I installed octolapse at the end of march
yes but I had to cheat a little bit so there is at least one tab hidden : Using the Firefox dev tool, I shrinked the tab's div ( class="tabbable span8" ) to 500px so the "timelapse" tab is being hidden
And then the problem was the same
If I shrink even more the div, more tabs get hidden and the problem occurs on every one of them
OctoPrint 1.4.0.dev1190+gd8eb5754
Raspbien 9.4 on rpi3
prusa mendel w/ marlin 1.1.8
Firefox 60.0 x64 on windows 10
not sure it would help :
octoprint.log
n/a
in the firefox console there is only two things concerning octoprint about mixed active content being blocked :
Blocage du chargement du contenu mixte actif (mixed active content) 芦 http://prusa.home:5000/static/vendor/font-awesome-3.2.1/fonts/fontawesome-webfont.woff?v=3.2.1 禄[En savoir plus] vendor.0c31c91b2f.js:37:69967
Blocage du chargement du contenu mixte actif (mixed active content) 芦 http://prusa.home:5000/static/vendor/font-awesome-4.7.0/fonts/fontawesome-webfont.woff2?v=4.7.0 禄[En savoir plus] vendor.0c31c91b2f.js:37:69967
The javascript console is not very usefull :
Less has finished and no sheets were loaded.
Starting dependency resolution...
... dependency resolution done
Initial application setup done, connecting to server...
Connected to the server
Safe mode is active. Third party plugins are disabled and cannot be enabled.
Finalizing application startup
Going to bind 26 view models...
Did not bind view model SoftwareUpdateViewModel to target #wizard_plugin_softwareupdate since it does not exist
User gege logged in
... binding done
Application startup complete
included above
I have read the FAQ.
Additional info虏 : Tested with microsoft Edge and the problem is the same (except the glich is not visible, but the anchor in the adress bar briefly changes and revert back)
Problem is caused by a sanity check in the hash switch function which is supposed to not allow switching to (invisible) tabs for which the permissions are lacking. Sadly that also triggers for tabs that are invisible due to not fitting into the tab bar. Need to find a workaround for that...
Hi Gina
What about adding some data-* attribute on the hidden tab's div, and rely on that to know wheither or not the corresponding panel can be shown ?
something like data-authorized="no|yes" or whatever ?
Tricky since that would require a whole ton of modifications also in plugins for it to work. But I might just have found another solution, just testing out some stuff.
Fixed I think by the above commit, at least I cannot reproduce it anymore and based on my own understanding of how it could happen it also should not be possible to happen anymore. Thanks for reporting this!
I just updated my OP instance and I can't reproduce it too, so I guess it's definetly OK
thank YOU for this amazing software and all the work you do on it
Most helpful comment
I just updated my OP instance and I can't reproduce it too, so I guess it's definetly OK
thank YOU for this amazing software and all the work you do on it