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.

Sign up for GitHub

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

Jump to bottom

WebContents background color is not set early enough in some cases. #27592

Closed
3 tasks done
marekharanczyk opened this issue Feb 2, 2021 · 4 comments
Closed
3 tasks done

WebContents background color is not set early enough in some cases. #27592

marekharanczyk opened this issue Feb 2, 2021 · 4 comments
Labels
9-x-y 10-x-y 11-x-y 12-x-y component/BrowserWindow has-repro-gist Issue can be reproduced with code at https://gist.github.com/ platform/all stale status/confirmed A maintainer reproduced the bug or agreed with the feature

Comments

@marekharanczyk
Copy link
Contributor

Preflight Checklist

  • I have read the Contributing Guidelines for this project.
  • I agree to follow the Code of Conduct that this project adheres to.
  • I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

  • Electron Version:
    • 13.0.0-nightly.20210129
  • Operating System:
    • any
  • Last Known Working Electron version:

Expected Behavior

Child window content background color set early before page loads.

Actual Behavior

Child window is white, then switch to background color, then page background color.

To Reproduce

https://gist.github.com/6710c5cd8ed5810fb5c796854d726c3a
Just click "Open child" button and look at what is displayed.

Screenshots

Additional Information
marekharanczyk added a commit to marekharanczyk/electron that referenced this issue Feb 2, 2021
@marekharanczyk
fix: set WebContents background color ubiquitously electron#27592
683e65c 
Move it from LoadURL to RenderViewCreated which is present
in all window creation cases and is called early enough to be
relevant from user prespective and after RenderWidgetHostView
is already present.
marekharanczyk added a commit to marekharanczyk/electron that referenced this issue Feb 3, 2021
@marekharanczyk
fixup! fix: set WebContents background color ubiquitously electron#27592
e0a5da8
marekharanczyk added a commit to marekharanczyk/electron that referenced this issue Feb 3, 2021
@marekharanczyk
fixup! fix: set WebContents background color ubiquitously electron#27592
e4863f9
@ckerr ckerr added 10-x-y 11-x-y 12-x-y 9-x-y component/BrowserWindow has-repro-gist Issue can be reproduced with code at https://gist.github.com/ platform/all status/confirmed A maintainer reproduced the bug or agreed with the feature labels Feb 3, 2021
@ckerr
Copy link
Member

ckerr commented Feb 3, 2021

Confirmed: when I press the Open child button in the gist, a new white window pops up, then changes to the background color specified in the BrowserWindow constructor options object's backgroundColor property, then the URL is loaded.

Tested with 9.0.0, 11.0.0, and 12.0.0-beta.20 on Ubuntu 20.10

marekharanczyk added a commit to marekharanczyk/electron that referenced this issue Feb 5, 2021
@marekharanczyk
fix: set WebContents background color ubiquitously electron#27592
2778d3a 
Move it from LoadURL to RenderViewCreated which is present
in all window creation cases and is called early enough to be
relevant from user prespective and after RenderWidgetHostView
is already present.
marekharanczyk added a commit to marekharanczyk/electron that referenced this issue Feb 10, 2021
@marekharanczyk
fix: set WebContents background color ubiquitously electron#27592
08523b4 
Move it from LoadURL to RenderViewCreated which is present
in all window creation cases and is called early enough to be
relevant from user prespective and after RenderWidgetHostView
is already present.
codebytere pushed a commit that referenced this issue Feb 10, 2021
@marekharanczyk
fix: set WebContents background color ubiquitously #27592 (#27593)
87064e5 
Move it from LoadURL to RenderViewCreated which is present
in all window creation cases and is called early enough to be
relevant from user prespective and after RenderWidgetHostView
is already present.
codebytere pushed a commit that referenced this issue Mar 1, 2021
@marekharanczyk @codebytere
fix: set WebContents background color ubiquitously #27592 (#27593)
8d5ddf2 
Move it from LoadURL to RenderViewCreated which is present
in all window creation cases and is called early enough to be
relevant from user prespective and after RenderWidgetHostView
is already present.
MarshallOfSound pushed a commit that referenced this issue Mar 1, 2021
@codebytere @marekharanczyk
fix: set WebContents background color ubiquitously #27592 (#27593) (#…
fd629c1 
…27942)

Move it from LoadURL to RenderViewCreated which is present
in all window creation cases and is called early enough to be
relevant from user prespective and after RenderWidgetHostView
is already present.

Co-authored-by: marekharanczyk <48673767+marekharanczyk@users.noreply.github.com>
@dependabot dependabot bot mentioned this issue Mar 8, 2021
Closed
@vadim-termius
Copy link
Contributor

I think the related changes added a blink of white color for app.allowRendererProcessReuse = false.

If you add the app.allowRendererProcessReuse = false line here: https://gist.github.com/marekharanczyk/6710c5cd8ed5810fb5c796854d726c3a#file-main-js-L3, the parent window will blink with white color.

This is reproducible in electron 11.4.x, but not in electron 11.3.0.

I know, that allowRendererProcessReuse was removed recently in the upstream, but this is still important for previous electron versions that support allowRendererProcessReuse.

cc @codebytere

@github-actions
Copy link
Contributor

github-actions bot commented Oct 6, 2022

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the latest version of Electron or in the beta—please include it with your comment!

@github-actions github-actions bot added the stale label Oct 6, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Nov 5, 2022

This issue has been closed due to inactivity, and will not be monitored. If this is a bug and you can reproduce this issue on a supported version of Electron please open a new issue and include instructions for reproducing the issue.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
9-x-y 10-x-y 11-x-y 12-x-y component/BrowserWindow has-repro-gist Issue can be reproduced with code at https://gist.github.com/ platform/all stale status/confirmed A maintainer reproduced the bug or agreed with the feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ckerr @marekharanczyk @vadim-termius