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

Allow setting the browser's background color during attributes #197

Closed
1 of 2 tasks
chippers opened this issue Apr 23, 2021 · 19 comments · Fixed by #662
Closed
1 of 2 tasks

Allow setting the browser's background color during attributes #197

chippers opened this issue Apr 23, 2021 · 19 comments · Fixed by #662

Comments

@chippers
Copy link
Member

chippers commented Apr 23, 2021

Is your feature request related to a problem? Please describe.
Allow the user to set a background color for the webview window to render while loading content. This is typically the step between the os window initializing the webview, and the webview initializing the application.
tauri-apps/tauri#1564 (my comment)

Describe the solution you'd like
Having a background_color field on wry::Attributes (I think that is the proper place for it).
I don't know which format we should accept the color in...

  • hex string?
  • rgb struct?
  • rgb tuple?
  • other?

Describe alternatives you've considered
none yet

Would you assign yourself to implement this feature?

  • Yes
  • No (I am not familiar with the macOS code and don't have access to an macOS machine)

Additional context
The linux part seems easy enough once a format for accepting the color is decided on. Some pseudo-code to replace:

// Transparent
if transparent {
webview.set_background_color(&RGBA {
red: 0.,
green: 0.,
blue: 0.,
alpha: 0.,
});
}

with

let alpha = (!transparent) as i8 as f64;
webview.set_background_color(&RGBA {
  red: bg_color.red,
  green: bg_color.green,
  blue: bg_color.blue,
  alpha,
});

assuming bg_color is some sort of struct with red, blue, green fields of f64.

I assume webview2 and macOS has a way of setting the background color but I'm not familiar with them yet

@lucasfernog
Copy link
Member

  • hex string?
  • rgb struct?
  • rgb tuple?
  • other?

I think we're following whatever is the standard on the winit API.

@amrbashir
Copy link
Member

amrbashir commented Apr 23, 2021

if we allow setting the webview background color, I think users will also expect the winit::Window to be of that color too.

So I think we can do one of the following:

  1. Always set the webview background to be transparent and provide a method on winit::WindowBuilder to change the color (ideally we want to set the color before showing it).

  2. Change both the webview and the winit::Window.

As to which format, winit has a unix specific struct called ARGBColor
https://docs.rs/winit/0.24.0/winit/platform/unix/struct.ARGBColor.html

@chippers
Copy link
Member Author

I see an ARGB struct on winit docs for unix platforms, but nothing for colors on all platforms. I also don't see a way to set the window background color while looking through the docs, is that something that can even be provided by winit?

@amrbashir
Copy link
Member

amrbashir commented Apr 23, 2021

@wusyong implemented a WindowExtWindows and WindowExtUnix traits so we can add them there, not sure about macOs (don't know if it have an api for that) but I guess possible.

@lemarier
Copy link
Member

lemarier commented Apr 23, 2021

In macOS to set webview transparent we could use something like;

let Color: id = msg_send![class!(NSColor), clearColor];
let () = msg_send![webview, setOpaque:NO];
let () = msg_send![webview, setBackgroundColor:Color];

We could write some helper for NSColor to use hex color by example so I don't see any issue for macOS.

@wusyong
Copy link
Member

wusyong commented Apr 24, 2021

It's possible to set the background color on HTML already like this:
<body style="background-color:rgba(87,87,87,0.5);">hello</body>

@lemarier
Copy link
Member

It's possible to set the background color on HTML already like this:
<body style="background-color:rgba(87,87,87,0.5);">hello</body>

I think it still flash as the webview has a default background color before the CSS is interpreted.

@wusyong
Copy link
Member

wusyong commented Apr 24, 2021

Maybe it won't if we set transparent to the window and webview.
Btw I just realize we haven't updated transparent option on Windows.
Stable release of webview2 have DefaultBackgroundColor for us to do it.

@amrbashir
Copy link
Member

Maybe it won't if we set transparent to the window and webview.

This is kinda scary, having the window transparent all the time, can have some side effects.
Check the second video in this tauri-apps/tauri#1564 and I remember electron also had unwanted behaviors when transparent option was on, we don't want to force it on users.

However we can set the webview to always be transparent and provide users with a method to change the window background.

@chippers
Copy link
Member Author

It's possible to set the background color on HTML already like this:
<body style="background-color:rgba(87,87,87,0.5);">hello</body>

This doesn't work because there's 3 color stages

  1. OS window color (I don't think there's a cross platform way of setting this)
  2. Webview background color (nothing has loaded yet)
  3. html page background color

see my video on tauri-apps/tauri#1564 (comment) to see all 3. I think we can get 2 and 3 working fine enough, I'm not sure of a cross platform way of doing 1.

The red flash will still happen with <body style="background-color:rgba(87,87,87,0.5);">hello</body> because there is still the step 2. My video used the api example, which has the spreadsheet in <head>. The red flash is slightly longer than inline body style because it waits to finish loading the stylesheet before the first painting, but they both still have them.

@amrbashir
Copy link
Member

amrbashir commented Apr 24, 2021

OS window can be styled too:

  • Windows: we can respond to WM_ERASEBKGND and paint the background.
  • Linux-GTK: we can provide a custom css and use CssProvider
  • MacOS: seems possible but I am not familiar with the api

@keiya01
Copy link
Member

keiya01 commented Jun 14, 2022

Could I take on this issue?
And is there a point to take care ?

@wusyong
Copy link
Member

wusyong commented Jun 17, 2022

Hmm this one is old. My stand is still we can make window and webview transparent and that's enough. People can always decide color on their html page

@keiya01
Copy link
Member

keiya01 commented Jun 17, 2022

I see. That's true.

@amrbashir
Copy link
Member

This is a nice to have feature and the code we use for transparent, can be slightly modified to also offer a way to set the color of the webview background so I don't see why wouldn't we offer this API also.

@FabianLars
Copy link
Sponsor Member

I think this could also help with the white flashes when resizing, so that resizing the WebView doesn't look as laggy as it is.

@Sid911
Copy link

Sid911 commented Jun 17, 2022

I just found the thread looking for answers to see if there is a setting to be changed for background color for webview or window.

Just as a note : for resize flashes color to the body itself is fine enough other than for the weirdness below

It would be awesome if this could be implemented, and released later on.
Also, sorry for hijacking the thread. Is this bug known during resize? The image below is a frame between resize (I am on debug build, I haven't testing in release). I am trying to reduce visual anomalies.

image

@amrbashir
Copy link
Member

@Sid911 please open another issue for this or ask in our discord.

@Silvea12
Copy link

Silvea12 commented Jul 15, 2022

I don't know if this is even possible to do, but I found Chromium's solution here:
https://codereview.chromium.org/296003010

When the window is resized, some drivers clobber the back buffer.
Unfortunately that can happen in the middle of a frame, and so we lose part
of what we've drawn and don't know it until we swapped (resulting in
flashes).

So instead, we create a child window, with a CopyFromParent visual (to avoid
inducing extra blits in the driver), that we can resize exactly in Resize(),
correctly ordered with GL, so that the buffer clobber is at the beginning of the
frame, before we will draw anything to it.

Actual patch: https://codereview.chromium.org/296003010/patch/1/10001

Gist of the patch: create a second window using the CopyFromParent flag and using that for the draw context. When it comes to resizing, you sync on GL, then perform the resize, and then sync on X.

It was brought up that this may not fix Wayland, but I was unable to reproduce the flicker they were describing on wayland (though I was using pixmap through xorg, so the issue may not have presented itself as a result).

Whether this is even possible to do - whether in wry or tao - I have no idea. But worth documenting regardless.

See https://discord.com/channels/616186924390023171/997615505223450624 for prior discussion on this.

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

Successfully merging a pull request may close this issue.

9 participants