Shared Storage - Githubissues

hasparus commented 2 years ago

Closes https://github.com/dethcrypto/ethereum-code-viewer/issues/24

Goal: Settings should be merged between all Ethereum Code Viewer domains

Currently, for every Etherscan instance (i.e. blockchain explorer with Etherscan-compatible API and URL scheme), we have a rewrite in Vercel config pointing to the same app.

In every domain we're hosted on, VSCode saves data to LocalStorage and IndexedDB using:

BrowserStorageService defined in src/vs/platform/storage/browser/storageService.ts
IndexedDB file system provider with file schemes 'vscode-userdata' and 'vscode-log'.

We could mess with the VSCode host implementation and move the storage itself to an iframe.

Instead, we're moving the app to one domain ecv.deth.net which can be opened inside of an iframe, and all existing domains will be from now on just entry-points.

Thus, Ethereum Code Viewer has 3 "levels" from now on.

Caveats

getLayoutMap

Running the app in the iframe instead of a "storage iframe" simplifies storage, but we encounter a problem due to privacy mitigations of navigator.getLayoutMap.

Failed to execute 'getLayoutMap' on 'Keyboard': getLayoutMap() must be called from a top-level browsing context.: Error: Failed to execute 'getLayoutMap' on 'Keyboard': getLayoutMap() must be called from a top-level browsing context.

See https://wicg.github.io/keyboard-map/#privacy-mitigations.

I've worked around it by exposing top-level getLayoutMap by post-message from top-level iframe and monkey-patching navigator.getLayoutMap in the vscode-host, but shadowing [keyboardLayoutService.ts] might have been an alternative (possibly better?) solution. I'm still not 100% sure if shadowing/swizzling incurs less maintenance burden than monkey-patching in the long term.

[keyboardlayoutservice.ts]: https://github.com/microsoft/vscode/blob/2d23c42a936db1c7b3b06f918cde29561cc47cd6/src/vs/workbench/services/keybinding/browser/keyboardLayoutService.ts

document.title

We'd like VSCode to be responsible for setting document title again.

I've added a MutationObserver to watch for document.title changes. Alternatively, we could "swizzle/shadow" in VSCode's browser/parts/titlebar/titlebarPart.ts, but I'm trying to avoid shadowing whenever it's possible.