electron: Default BrowserWindow's backgroundColor is not #FFF

Electron version: 1.7.4, 1.6.11
Operating system: Windows 10

Expected behavior

Default background color is #FFF as described in the documentation. And texts don’t have grayscale anti-aliasing. ( <webview> also should have #FFF background (NOT CSS background) by default.)

Actual behavior

BrowserWindow shows different rendering when using backgroundColor: '#FFF' in the constructor.

antialiasing_vs_backgroundcolor

How to reproduce

Use backgroundColor in BrowserWindow constructor.
Load a html.

<!DOCTYPE html>
<html>
<head>
</head>
<body>
  <p>Electron</p>
</body>
</html>

As far as reading #6344, the window doesn’t have background color when not specifying backgroundColor. This might cause other anti-aliasing/blurry-text issues like #8708. When I set backgroundColor, I got good anti-aliasing as well as Chrome.

And due to this anti-aliasing behavior, <webview> also should have #FFF background (NOT CSS background) by default.

Possible fixes

I think the problem is that there are two ways to set background color.

native_window.cc tries to set #FFF by using SetBackgroundColor(), but its implementation is different from atom_api_window.cc. And atom_api_window.cc doesn’t set #FFF when backgroundColor doesn’t exist, so the background is not set to #FFF.

Unfortunately I could not imagine a consist way to resolve this.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 13
Comments: 21 (5 by maintainers)

Commits related to this issue

Improve font rendering This is a long known issue of the Electron framework and in https://github.com/electron/electron/issues/10025 is described the used workaround. — committed to c3er/mdview by c3er 6 years ago
Improve font rendering This is a long known issue of the Electron framework and in https://github.com/electron/electron/issues/10025 is described the used workaround. — committed to luxuereal/md_viewer_electron by deleted user 6 years ago
Improve font rendering This is a long known issue of the Electron framework and in https://github.com/electron/electron/issues/10025 is described the used workaround. — committed to luxuereal/md_viewer_electron by luxuereal 6 years ago

Most upvoted comments

The Electron version reported on this issue is no longer supported. See our supported versions documentation.

If you’re still experiencing this issue on a supported version, please open a new issue with an updated repro - a Fiddle is very appreciated.

Electron has a large issues backlog. To help our team prioritize, we’re closing older issues and asking for new issues with updated repro steps if it affects a supported version. This helps sort what issues are still relevant and helps us fix them more quickly.

Thanks for your patience and understanding!

electron-triage on Mar 10, 2021

Yes. Possibly another color may also be okay (I didn’t test). The documentation says the default value is #FFF, but I got different results.

yuya-oc on Jul 17, 2017

@stanleyxu2005

a pretty clear described issue going to be closed without a valid reason.

The blocked label has already been removed indicating a maintainer has seen the response confirming the issue is still present, as the original message stated we aren’t going to close issues if a response is received within those 7 days.

Once it is closed, people cannot reopen the issue except admin. This will actually increase the maintainers load.

We are well aware, this is why we post the 7 days comment before actually mass-closing issues for EOL versions.

By the way, if original author closes an issue but it is still reproducible. Shall we create a new issue, or how to capture core team’s attention to reopen it? Issue like --> this <–

I can’t speak for other maintainers but I have a set of issue / notification filters and because that issue was closed by the original reporter and not by me or another maintainer it won’t appear in the same category as other issues I review the comments for. Normally I’d re-open issues like that but could you raise a new one for that with detailed information, that issue thread is 95% random comments with different repros so it’s not clear if it’s all the same issue. Raising one new issue with a clear repro would probably be more productive than re-opening that old one 👍

Notifications are hard 😆 E.g. This is just from the last few days 🤷‍♂

MarshallOfSound on Aug 11, 2019

You can leave it open, or you might say “After further investigation the root cause is in the Chromium core. We have raised an issue to Chromium community.” But label it as “blocked/need-info” is not appropriate. It makes me think the Electron Official closes issue without doing any real verification. There is no merged bugfix PR in this thread, isn’t it?

@stanleyxu2005 There are over 1200 issues currently open on the Electron repository. If we assume it takes 10 minutes to verify each issue (which is incredibly generous, some issues don’t have code samples or even good repro instructions) then it would take around 25 working days of testing, 8 hours a day to verify each individual bug, that is quite simply not realistic.

We have a system where-by old issues that are labelled with an EOL electron versions get a standard message pasted on them by @sofianguy (who does an awful lot of work here so 👏 ) asking the person who raised the issue or anyone interested in the issue to verify that it is in fact still an issue.

We find a large quantity of issues are resolved over time due to architectural changes, chromium upgrades or v8 version bumps and as previously mentioned the Electron team does not have the resources to spend 200 hours verifying all the open bugs.

This is an open source project and we need and ask for help from community members such as yourself with things like this where you can make the maintainers load a little lighter. Your attitude to this very simple “is this still an issue” request should probably change a bit.

MarshallOfSound on Aug 10, 2019

Thank you for taking the time to report this issue and helping to make Electron better.

The version of Electron you reported this on has been superseded by newer releases.

If you’re still experiencing this issue in Electron v4.2.x or later, please add a comment specifying the version you’re testing with and any other new information that a maintainer trying to reproduce the issue should know.

I’m setting the blocked/need-info label for the above reasons. This issue will be closed 7 days from now if there is no response.

Thanks in advance! Your help is appreciated.

sofianguy on Aug 9, 2019

@stanleyxu2005 I think they just try to close all issues up to a certain version number and hope that the bugs either got away or there is at least no one anymore who is bothered by that issue. 😉

@sofianguy I just reproduced this issue with Electron 6.0.1!

c3er on Aug 10, 2019

@codebytere The same problem exists still in Electron 3.0.0.

blackknifes on Sep 29, 2018

This finally explains my ancient gripe with unclear text in Electron apps. Confirmed that setting the backgroundColor property on the BrowserWindow options enables subpixel antialiasing.

Logically the solution should be to actually set the background color to white as per the documentation, or to update the docs to reflect reality. I don’t know if there are reasons to go with the latter, but personally I would prefer the former.

Lombra on Aug 17, 2018