We fetch settings once explicitly after passive login but before
completed startup. Without this patch we fetched them again after
onUserLoggedIn got fired (if it got fired by the passive login)
during startup. That's not necessary because we did the passive login
before our initial settings fetch, so IF that already logged us in,
our settings fetch already was done with us logged in as well and
the onUserLoggedIn later only tells us what we already knew.
We still had some concurrent requests triggered through onStartup that
managed to overtake the passive login (and hence nuke the session
data on the client). This should now really not be possible any longer.
Also created a sequence diagram of the new process and linked it from
a lengthy comment.
It caused issues with our line number tracking in the browser
developer tools and I don't see any way to avoid this considering
that we can't adjust the arguments supplied to console.log without in
fact wrapping it :/
Under specific circumstances it could happen that the passive login
response was overtaken by a response from an earlier still
unauthenticated request which would then effectively overwrite the
session cookie immediately and hence cause the browser to use its
login session against the server, but without displaying that to the
user. See #1881 for what is probably an issue caused by exactly this
kind of scenario.
Additionally a couple of requests needed to be done a second time
after login, just moments after having done them for an anonymous
user. See #1572 for a request to change this behaviour.
This patch changes the startup order of the web interface like this:
1. connect to the websocket, postpone any events triggered by
this (e.g. "fromHistoryData") until 3
2. perform a passive login, postpone any events triggered by this
(e.g. "onUserLoggedIn", "onUserLoggedOut") until 4
3. trigger postponed events from 1
4. trigger "onStartup" (triggers postponed events from 2)
5. fetch settings
6. bind view models etc
A connection close of the websocket will disable event processing on the
socket until it is marked as initialized again by the passive login
processing, which will also be triggered immediately on server connect.
That way under normal circumstances nothing should ever get triggered
in the registered view models that might generated requests to the
server API until a passive login has been done, a server session
initialized and if necessary a user properly authenticated.
They might be nozzle priming routines which are not actually part of
the model proper and hence it doesn't make sense trying to keep them
visible when zooming in on the model, or allowing them to offset the
model center.
Now also detects capabilities reported by (extended) M115 output and
if AUTOREPORT_TEMP is available enables it with the configured
autoreport interval and disables active polling.
Implements #1679
See #1942
This does NOT fix the root cause of `_default.profile` becoming an
empty file (apparently during migration from config.yaml?), however
since this particular situation was impossible to reproduce so far this
workaround for the consequences will have to suffice for now since we
want a hotfix as fast as possible for 1.3.3.
* fa-circle-blank does not exist, replaced with fa-circle-o (see also
report in #1928)
* fa-trash-o instead of fa-trash (same look and feel)
* fa-check instead of fa-check-circle (same look and feel)
* fixed toggleContent binding to also be able to toggle fa icons
* fix deletion spinner in file list (was still using old icon-
classes which of course weren't there anymore and hence not
toggleable)
* icons-ul => fa-ul
* remove superfluous fa class from some places
Follow-up to #1915.
Instead of disabling capturing of postroll by default (which we actually
don't want and doing so was a mistake thanks to misremembering the
meaning of the variable in question), we now properly reset the
default value for that check box (which wasn't properly set only due to
a very stupid typo).
That fixes up the relative URLs to the font files and should make updates down the line
a thing of a quick copy and paste (plus allow some more sophisticated dependency
management down the road as well).
Also renamed fonts folder for FontAwesome 3.2.1 from font to fonts, for more
consistency.
Otherwise we will block ourselves, waiting for the restart command to
complete which it only can when we are no longer there.
Should reduce restart times on update significantly.
Downside is that we no longer can wait for the return code of the
call. However, that should be caught by our UI handler timing out for
the restart and showing an error prompting the user to restart
manually.
