Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Electron alpha: on start up when dark theme is enabled the electron app flashes white before it gets colored in the right theme #1410

Closed
rainerzufall opened this issue Aug 30, 2017 · 7 comments · Fixed by #3083

Comments

@rainerzufall
Copy link

Bug description

on start up when dark theme is enabled the electron app flashes white before it gets colored in the right theme.

Expected result: signal electron is colored in the right theme right away

Screenshots

flash on start up

Platform info

Operating System: Windows 7 64 bit
Signal version: Electron alpha 1.0.22

@scottnonnenberg
Copy link
Contributor

This is a great opportunity to talk design, since you are invested. :0)

That first light-colored loading screen is the base HTML of the page, shown before any Javascript loads up. That's why it shows so fast. Once the application loads, it adds your customized theme class to the page and the proper styles take effect.

All that to say: there's nothing we can really do here. One way to get rid of that flash is to make the loading screen light-colored all the time.

What do you think?

@rainerzufall
Copy link
Author

rainerzufall commented Aug 30, 2017

That's a tough one!

So we have three subsequent screens:

  1. the base HTML page // which could be manipulated, right?
  2. loading screen before customized theme class is added // which could be manipulated, right?
  3. loading screen after customized theme class is added // is already manipulated.

If 2. can't be manipulated, there is only one option - make the loading screen light-colored all the time. Maybe a fade out could be added? Even if not, I would say that the resulting flash from a white loading screen to a dark theme does look less irritating compared to what's happening now. Just my intuition at the moment though.

If 2. can be changed. One could think about consistent "signal blue" background for 1., 2., 3. (Like the first welcome screen during migration). Ideally supplemented by a fade out as well.

@scottnonnenberg
Copy link
Contributor

scottnonnenberg commented Aug 30, 2017

First, 1. and 2. are essentially the same in this case.

Yep, I suppose we could go find the html file on disk and modify it based on a user setting before we open the window. But that would be a reasonable amount of work.

Likely the right solution, as you suggest, is a different design entirely. 'Signal blue' is neither light nor dark, and is already used for the initial setup screens.

@liliakai
Copy link
Contributor

liliakai commented Aug 31, 2017

Has anyone tried playing with passing in the backgroundColor option to BrowserWindow creation in main.js? If it does what it says on the tin, then the hard part would changing where the theme setting is stored. Currently it's in IndexedDB which takes a while to load after we open the window... So probably it would need to be moved to userConfig, which is where the other window settings live now.

https://electron.atom.io/docs/api/browser-window/

@scottnonnenberg
Copy link
Contributor

Yep, a "reasonable amount of work" as I said above. We'd need the actual user setting, no matter whether we specify backgroundWindow or simply add a class to the html before we hand it to createWindow. And that's a new system we'd have to thread into the app - saving a user setting currently in IndexedDB into the parent Electron process via IPC.

A bit too much engineering for my taste, when we could use a new, neutral design to skirt the whole issue.

@rainerzufall
Copy link
Author

some additional information when thinking about solving this issue. It is not only the colouring which changes, it is also the localization. Here you can see how it changes from light theme & English to dark theme & German:
giphy

@scottnonnenberg
Copy link
Contributor

Yep, that's for the same reason. We start with static HTML, which isn't modified with user settings - neither theme nor language. The solution there may be to remove the text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

3 participants