As seen in https://groups.google.com/forum/#!msg/octoprint/DyXdqhR0U7c/kKMUsMmIBgAJ
a broken entry_points.txt in some arbitrary Python package installed in
the same python envrionment as OctoPrint can make our whole plugin
detection fail and hence interrupt regular server startup.
This adds better protection against such cases.
If snapshot url and/or ffmpeg path are not set, the timelapse cannot
work regardless of what type has been configured.
So if the current configuration still contains a timelapse type other
than "off" but snapshot url or ffmpeg path are unset, force a disabled
timelapse.
Fixes#2206
* Add comment with source file to JsDelimiterBundler and
JsPluginDelimiterBundler
* Include source file name in JsPluginDelimiterBundler catch
block and use log.error instead of console.error
At least unless we've selected git based tracking over release tracking.
This should greatly reduce the likelihood of not being able to update
due to some git repository corruption issues, as has happened to some
people in the past.
If either the full code or just the main code are blacklisted, only
upper case the code. Otherwise also upper case the parameter list.
In any case push originally entered command to history, not the
modified one.
Added new config setting: auto uppercase blacklist that is configurable
in the advanced option of the serial tab, with M117 included in the
default settings of the blacklist. Changed the sendCommand method in the
TerminalViewModel to auto uppercase the entire gcode command except when
gcode is in the blacklist. Updated documentation to include the default
auto uppercase blacklist command M117.
Resolves: #1026
(cherry picked from commit dbf7af1)
We didn't reset the capability flag and also didn't resend M155. Now we
do at least the latter if we detected that the printer supports
temperature auto reporting earlier.
A centralized plugin blacklist read from plugins.octoprint.org on server
start now allows us to stop plugins from being loaded that are known to
cause severe issues with OctoPrint's regular operation.
Blacklist entries can be restricted for specific plugin versions &
OctoPrint versions, allowing for very granular control of any kind of
blocking.
Additionally users may disable blacklist processing in general (an
opt-in wizard and a new section in the settings have been added) and
at server start via the new --ignore-blacklist parameter available for
"octoprint serve" and "octoprint daemon".
If a plugin is blacklisted, OctoPrint will not even import the
plugin module in question (if only a plugin key is specified OR a key
and a version and the plugin's version is already known during import
time, which is the case for plugins loaded from entry points) or at the
very least stop the plugin from being enabled (if a plugin key and a
version is specified and the plugin's version is only known after
loading, which is the case for plugins loaded from directories).
Sets server.startOnceInSafeMode flag to true. Probably easier for a lot
of people than editing a config file or running OctoPrint manually from
command line, in case the built-in "Restart in safe mode" system command
is not an option.
We so far only protected the binding process itself against errors
triggered inside view models. Now we are also more resilient against
issues arising in view model callbacks like onBeforeBinding,
onBoundTo and onAfterBinding as well as exceptions during plugin
instantiation itself.
Triggered by jneilliii/OctoPrint-TPLinkSmartplug#19 which was also
reported on OctoPrint's tracker as #2168, #2170 and #2171 and on OctoPi
as guysoft/OctoPi#427.
There are too many printers out there with crappy electronics that are
just waiting to go up in smoke, and people keep leaving those alone
because "they are monitoring them via OctoPrint, so nothing can happen".
So let's add a safety warning, in the hopes that will bring at least
some people to their senses or at the very least force them into making
the conscious decision to blow all warnings into the wind.
Firefox doesn't trigger dragleave if the mouse leaves the browser
window to another window on top during an active drag. That leaves
OctoPrint stuck with the drag-n-drop overlay.
Adding a timeout for dragover for only Firefox that clears the overlay
solves this issue.
Solves #2166
