In the wild, ships that were live pre-OS1 still had launch subscriptions
open to the clock on the /tile path, instead of the currently-used
/clocktile path. Additionally, launch state for the clock tile seemed
incomplete.
Here, we simply re-%add the clock to launch.
Note that launch currently does not clean up old subscriptions on
path change. For the pre-OS1 case, the old path is no longer in use,
rendering the subscription harmless. For cases where the correct
subscription was already in place, it'll print a %watch-wire-not-unique,
but doesn't do any harm besides that.
Previously, when the refresh-rate timer activated, and the thread from
the previous activation was still running, we would kill it and start
a new one. For low refresh rates, on slower machines, nodes, or network
connections, this could cause the update to never conclude.
Here we add a timeout-time to eth-watcher's config. If the refresh-rate
timer activates, and a thread exists, but hasn't been running for at
least the specified timeout-time yet, we simply take no action, and wait
for the next refresh timer.
Note that we opted for "at least timeout-time", instead of killing &
restarting directly after the specified timeout-time has passed, to
avoid having to handle an extra timer flow.
In the +on-load logic, we configure the timeout-time for existing
watchdogs as six times the refresh-rate. We want to set
azimuth-tracker's timeout-time to ~m30, and don't care much about other,
less-likely-to-be-active use cases of eth-watcher.
A syntax typo led the array for nested notebooks to not have paths
pushed into it. Only the last item in the group would be pushed into the
array. This commit fixes that typo.
Across every OS1 module (including the launch/home screen context) I edited some padding/margin/sizing for navigational elements for consistency across paging.
During the #2607 upgrade, strictly local collections got left out of the
listening set. (Because they did not have any outgoing subscriptions.)
This led to personal collections not being available on the frontend.
Here, we add upgrade logic for adding those back to our listening set again.
If a user had explicitly left a personal collection (instead of deleted it, for
whatever reason), they will have to leave it again. This case seems much more
rare than the "my collection is gone" one.
Events always pass through these, adding to the stack trace on-crash.
This information is practically never useful, however. Adding !. leaves
these cores out of the traces.
(Re)subscribing gets us a %contacts update, containing the full set of
contacts as it currently exists.
Previously, we would fully delete our local state, only to recreate it
using the data from the update.
Now, we never delete existing data, instead only creating if we don't
have it yet, and adding, removing or recreating contacts if they
changed.
In the future, we'll want an easy way to turn two contacts into an %edit
diff, to let us apply correct semantics to individual contacts, too.
Instead, %bundle and %add if we don't have the group locally yet,
or %add and %remove whatever the difference is between the local group
and the group as specified in the %path update.
In both, we make clear that the wire is always of the /@/group/^ form,
and alias the "group path" portion of the wire for clarity.
For kick, more obviously reuse the same wire, don't reconstruct it.
For watch-nack, only delete from the synced map if the source of the
watch-nack is still relevant. While we don't expect this to be relevant
considering current mode of operation, this does protect us against
strange cases.
Deletion retains its old behavior: can only be done by group owner, and
propagates.
Removing can now always be done by anyone, and works using
link-listen-hook: removing the collections from the set of ones we're
interested in, no longer syncing or showing up in the sidebar.
Instead of going purely off metadata, we now track the collections we're
listening to, and allow the user to remove collections from that list.
This allows us to remove/ignore collections, without mutilating group
assocations locally.
We were taking care not to re-add something to our data store if we
already had it in there, but were still sending out an update
regardless.
With this, we only send out an update if we weren't previously aware
of the content.
Adds a disabled check during link submission to prevent duplicates.
Also fixes an unmarked bug where 'linkValid' was not being reset to
false on submission, allowing for submitting blank links after one
correct link has been submitted.
This commit introduces some refactoring of localStorage logic, copy
changes and a rearrangement of the launch welcome message to the top
of the screen.
Makes it so that |cancel %force skips the next thing in the queue if
you're not in the middle of something. If you are in the middle of
something, it skips the thing you're in the middle of (just like naked
|cancel).
This should resolve issues where |cancel doesn't drain the queue.
If you entered the web dojo and hit Backspace immediately,
it would still process it as a valid key but pass the whole key forward.
This adds a conditional to ignore the key in those cases.
Considering some of the options here were atoms, not cells, $% wasn't
appropriate, and led to *etyp:abi:ethereum resulting in ford %ride execution
failure. Simply using $? instead would result in a fish-loop, so here we split
the atom cases from the tagged union ones with a $@.
Previously, the pretty-printing for %incoming and %outgoing results was hanging
on to and displaying irrelevant type information: "_list_ of subscriptions",
"wire with _head and tail_", and so on.
Here, we move to producing tangs, instead of vases, and print those. For the
%incoming and %outgoing cases, we print a line for every subscription, sorting
them by path and wire respectively, and giving clean, easily readable output.
If chats with identical resource paths were created, that would result
in chat-hook seeing updates twice.
These "/mailbox wire sub to local chat-store" subscriptions aren't
created by the current logic anymore, and as such any existing ones
should be eradicated.
Introduced in #2546, the new functionality seems able to induce weird
behavior causing messages to be processed twice. Disabling this
functionality on the frontend until that has been fixed.
When you were looking at your own card in another group,
it would say "Remove from" group. This is from an arbitrarily strict
ternary check that adminOpt catches
for us, so we just check if the ship is us.
Before we saw if window.ship was in the path of the group.
If you're a star or higher, you'll match many group paths that you don't
own. This strengthens the check.
We were looking for the box in our contacts object, not the associated
group, so if you had a group and chat with the same name,
you'd see nicknames, but in no other situations. This commit rectifies
that by safely polling for the associated group of the chat.
