livebook-dev
When I replace the Livebook app on MacOS with a new version, my "Key bindings" setting resets to "Default"
I updated from 0.14.0 -> 0.14.2.
Expected: Key bindings setting would remain "VIM".
Observed: Key bindings setting reverted to "Default".
The settings related to code editor are stored in browser local storage, rather than persisted to a file, like other Livebook settings (because Livebook can be hosted and used by multiple users, and editor settings are specific to each user).
One thing I realised only now is that since local storage is scoped to origin (including port) and we use random ports for the desktop app by default, those settings are effectively lost on every restart. @wojtekmach @josevalim should we use a fixed, perhaps less popular port for the Desktop app?
@josevalim that should work, but then we unnecessarily increase the payload on every request to the server, so I'm not convinced we should do that.
Could we have a very simple encoding schema where we store only key-values as numbers? That should keep the server footprint minimal and only if you set the cookie in the first place. Or we use the cookie if localhost, which means we don't care about the footprint anyway?
Could we have a very simple encoding schema where we store only key-values as numbers?
What do the numbers point to?
Basically we would store everything as a Enum. So, for example, 1=1;2=2 could mean 1=1 (font_size=large) and 2=2 (editor=emacs).
I see, basically compressing by hand, but honestly I think that's too brittle.
Or we use the cookie if localhost, which means we don't care about the footprint anyway?
This sounds better, the main issue is that it's harder to detect issues, since now we have these separate scenarios.
Do you remember what was the issue with fixed port?
I think it is just about making sure the port is not being used. But we can pick one and cross our fingers. Or alternatively, we pick one, save to ETS, and use it the next time around.
Oh, the issue was #1282.
The error was
Slogan: Kernel pid terminated (application_controller) ({application_start_failure,livebook,{{shutdown,{failed_to_start_child,'Elixir.LivebookWeb.Endpoint',{shutdown,{failed_to_start_chil
d,{ranch_listener_sup,'Elixir.LivebookWeb.Endpoint.HTTP'},{shutdown,{failed_to_start_child,ranch_acceptors_sup,{listen_error,'Elixir.LivebookWeb.Endpoint.HTTP',eacces}}}}}}},{'Elixir.Live
book.Application',start,[normal,[]]}}})
eacces indicates more like reserved port, than port taken. I found related discussion in https://github.com/BrowserSync/browser-sync/issues/1668#issuecomment-986269204 and it looks like a rather specific issue, that can be fixed by running net stop winnat then net start winnat.
Also, at that point we didn't really show logs, but now when startup crashes we show the logs, and it says the port is taken, so it should be apparent to the user when that happens.
I think a fixed port is very convenient, so let's try reverting the random port? @josevalim @wojtekmach?
The issue is that, if the port is taken, the first user experience is a broken one. I would really like to avoid that. :(
Fixed port, and if conflict use a random port?
@josevalim we could actually do that, though I think it should only apply to the desktop app. wdyt?
In that case I would try to be consistent and apply it everywhere. But yeah, we could try it!
@josevalim I don't think it's a desired behaviour when running from CLI, especially in case of Docker, and starting on a random port would be rather unexpected.