Gcode viewer locked on current layer
Microwar99 opened this issue · comments
The problem
Octoprint Gcode viewer does not allow switching to next or previous layer. As soon as you click one of the buttons it reverts back to current layer.
Tested on Opera and Crome. (not Firefix as it's bugged)
Did the issue persist even in safe mode?
Yes, it did persist
If you could not test in safe mode, please state why ("currently printing" is NOT an excuse!)
No response
Version of OctoPrint
1.9.3
Operating system running OctoPrint
1.0.0 (build 2023.03.02.160739)
Printer model & used firmware incl. version
No response
Browser and version of browser, operating system running browser
Opera 103.0.4928.34 and Crome 118.0.5993.118
Checklist of files to include below
- Systeminfo Bundle (always include!)
- Contents of the JavaScript browser console (always include in cases of issues with the user interface)
- Screenshots and/or videos showing the problem (always include in case of issues with the user interface)
- GCODE file with which to reproduce (always include in case of issues with GCODE analysis or printing behaviour)
Additional information & file uploads
I am also seeing this with OctoPrint 1.9.3 and Chrome 117.0.59 or Safari 17.0. You can advance maybe one or two layers, but it soon reverts back to the current layer. It's as if the option 'sync with job progress' is always on - even if it's visually unchecked.
This used to work, so I might guess it is related to one of the recent OctoPrint updates.
I've now tested
- Ungoogle Chromium 118 on Linux
- Chrome 117 on Windows 10 (via BrowserStack)
- Opera 102 on Windows 10 (via BrowserStack)
and couldn't reproduce this on any of them.
My steps:
- Open the web interface
- Start a print job
- Switch to the GCODE viewer tab
- Use the scroll bar or the next/previous layer buttons to scroll to a different layer
- Confirm that the displayed layer doesn't change on running print job
I also tried to test with Safari 17 on macOS Sonoma and Safari 16.5 on macOS Ventura (both via BrowserStack) but saw some extremely weird Websocket issues there, so couldn't test.
So, currently, this is something I fear I have to mark as unreproduced - this doesn't mean that I'm denying it, but rather that currently I'm unable to reproduce and thus further debug it.
@Microwar99 your system info bundle shows that your last safe mode start was over a year ago. Could you please reproduce it in safe mode once more and send an updated bundle?
@edwardhorsford I take it it also persisted in safe mode for you? Could you please also provide a system info bundle?
@foosel I haven't tried in safe mode. I'm currently mid print, but can try later today.
That would be very helpful, as given that I cannot reproduce it here, chances are high that's either caused by a third party plugin or some other environmental factors, so we need to rule things out. Safe mode disables all third party plugins.
Do you happen to be using the UI Customizer plugin? I noticed this behavior when I had UI Customizer installed, but did a clean install on my server for unrelated reasons and the stock configuration seemed to clear this problem up
Do you happen to be using the UI Customizer plugin? I noticed this behavior when I had UI Customizer installed, but did a clean install on my server for unrelated reasons and the stock configuration seemed to clear this problem up
Yes, i do. Just tested in safemode, and it works as it should. Hope this gets fixed as I realy want to use the plugins i have.
Can do without the Vierwer working as it should for now, but reported this as somebody asked me to do it.
First i though it was related to the Firefox Big file bug.
Using Bed Leveling Wizard, Camera Settings, Cura Tumbnail, Dashboard, Exclude Region, FileManager, Navbar Temperature Plugin, OctoEverywere, Octolapse, Preheat Button, PrintTimeGenius Plugin, Simple Emergency Stop, Slicer Thumbnail and UI Customizer.
Edit: i see there is a bug report on thus at the UI Customizer page.
LazeMSS/OctoPrint-UICustomizer#308
Third party plugin issue then, that explains why I couldn't reproduce it 😅
A request for the future: please, when the template asks whether the issue persists in safe mode, don't just click "yes" when you haven't actually tested it. Safe mode detected exactly these kinds of situations where an issue is caused by a third party plugin, and actually testing in safe mode would have saved me 1h+ today spent with frantic attempts to reproduce this behaviour in various environments 😉
Asking for a test in safe mode is not an attempt to annoy y'all but a necessity part of debugging.