MetaMask / MetaMask/metamask-extension
[Bug]: we should never render a theme different from the user's selected theme
- Dominant language
- TypeScript
- Stars
- 13.2k
- Forks
- 5.6k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 451
Description
Our loading screens always use the system default theme, but the user may have selected a different theme.
Instead of only storing the users theme setting in `(browser|chrome).storage.local`, we could sync it to `localStorage`, which has a synchronous interface that can be used to set the page's theme correctly _before_ it the first render, eliminating a flash of the incorrect theme.
Because this setting is cleared whenever the browser starts up we'd need to occasionally sync it from `storage.local` to `localStorage` (like when the background starts up and on each initial page render).
Note: service-workers don't have access to `localStorage`, so syncing the value will have to be proxied through an interface that can.
Contributor guide
Research direction
Start by tracing how the selected theme is stored in browser or chrome.storage.local and how loading pages choose their initial theme. Examine the background startup and initial page-render paths, including the service-worker proxy needed to reach localStorage; done means the selected theme is available synchronously before the first render without an incorrect-theme flash.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100