You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Say that there are two applications, namely Alice and Log-viewer, hosted under example.com.
example.com/alice reads from / writes to key "theme" in the localStorage as JSON encoded values (e.g., "light").
example.com/log-viewer reads from / writes to key "theme" in the localStorage as string values (e.g., light).
The log viewer fallbacks to the "system" default theme when an arbitrary value is set on key "theme", but application Alice only expects JSON under the "theme" key and doesn't handle any non-JSON values (it just crashes with a white screen displayed).
Generically speaking this shared storage handling should apply to all configs, but since the issue is observed with theme settings, we will use it in the examples below.
It was discussed offline that:
For apps hosted on the same domain, they may not necessarily want to share the same configurations / handle the configuration values in the same format. This can be obvious for applications developed by different venders.
At the same time, seamless integration for apps hosted on the same domain, if not on different domains in the browser, is important. For example, the experience of one application (configured in dark theme) redirects to another application (configured in white theme) then a third application (configured in dark theme) can be annoying. By having a shared theme setting, the described scenario would not exist as all applications would either be all-dark or all-light.
That said, these days, all applications at YScope and most applications on the web switches their themes according to the user platform system's defaults, which is unified, unless the user has manually overridden such settings in the applications. By allowing individual applications to have their own theme settings to be overridden, we can provide the most flexibility to users.
Conclusion: individual apps should place their localStorage keys in their own namespaces
Bug
Say that there are two applications, namely Alice and Log-viewer, hosted under
example.com
.example.com/alice
reads from / writes to key "theme" in the localStorage as JSON encoded values (e.g.,"light"
).example.com/log-viewer
reads from / writes to key "theme" in the localStorage as string values (e.g.,light
).The log viewer fallbacks to the "system" default theme when an arbitrary value is set on key "theme", but application Alice only expects JSON under the "theme" key and doesn't handle any non-JSON values (it just crashes with a white screen displayed).
yscope-log-viewer version
07c3558
Environment
Google Chrome: Version 131.0.6778.265 (Official Build) (arm64)
Reproduction steps
See bug description.
The text was updated successfully, but these errors were encountered: