Temperature not displaying in plugins (NavBar and Fullscreen)

[KC703]

---

What were you doing?

Monitor temperature through Navbar Plugin and Fullscreen Plugin. No T0, T1 or Bed showing in devel (OctoPrint 1.4.0.dev690+gad246de (devel branch) running on OctoPi 0.13.0). Switched to Master branch and both plugins work.

Ideally provide exact steps to follow in order to reproduce your problem:

1. Install Navbar Temperature
2. Check for T0, T1, or Bed

What did you expect to happen?

Expect to see temperature of T0, T1, Bed

What happened instead?

No temperatures

Did the same happen when running OctoPrint in safe mode?

No... plugins disabled in safe mode

Branch & Commit or Version of OctoPrint

OctoPrint 1.4.0.dev690+gad246de (devel branch) running on OctoPi 0.13.0

Operating System running OctoPrint

Octopi distribution 0.13.0

Printer model & used firmware incl. version

Lulzbot TAZ 5 (Marlin 1.0.0.1)

Browser and Version of Browser, Operating System running Browser

Chrome (Version 62.0.3202.94 (Official Build) (64-bit))

Link to octoprint.log

<script src="https://gist.github.com/KC703/e2cf9167b160887e3d51c85ce93b12bb.js"></script>

Link to contents of terminal tab or serial.log

https://gist.github.com/KC703/27ada15a842356e26677c13800038ba8

Link to contents of Javascript console in the browser

[On gist.github.com or pastebin.com or alternatively a screenshot. If applicable -
always include if unsure or reporting UI issues.

The Contribution Guidelines tell you where to find that.]

Screenshot(s)/video(s) showing the problem:

[If applicable. Always include if unsure or reporting UI issues.]

I have read the FAQ.

[KC703]

Forgot to add that this just started happening with the recent commit to the devel branch... And since its two plugins affected it seems to be related to Octoprint.

[KC703]

Confirmed fixed in the recent commit.

Thanks!

[foosel]

Was already late yesterday and I forgot to comment... the issue is due to an implementation detail in the plugins in question that rely on global variable declaration. That is actually somewhat bad practice. The thing is that in #2200 we are looking into isolating plugins more from each other since they keep interfering due to various reasons, and this kind of isolation does not mix well with some global declaration practices.

This is only going to get worse if plugins are not isolated better, so expect some plugins to break with 1.3.6 - I'll try to mitigate this with loads of information sharing ramping up towards release, including approaching registered plugins that might be affected directly, but it will require minimal (backwards compatible) steps from plugin authors to fix.

I'll reopen this since the problem is not really solved - we DO need the isolation, so this will return, but I wanted to keep the maintenance and devel branches free from this problem until we have a minimal invasive solution figured out and implemented in #2200.

[foosel]

The isolation is now active again, so those plugins will again run into problems. I added a legacy mode however that can be enabled through a feature flag if needed for reasons of compatibility with existing plugins:

That should give plugin authors some time to adjust their plugins if they currently rely on variables or functions to be available in the global namespace that they didn't explicitly add to that.

See also my comments here and here on what is the problem here and how we'll proceed with regards to this.

[foosel]

Closing because 1.3.6 was just released.

[BillyBlaze]

The fullscreen plugin fix has been released too.

[foosel]

@BillyBlaze perfect, I've also updated the blog post accordingly: