1549943 - GeckoView cannot be transparent once HMTL has loaded

Status: NEW

(GeckoView :: General, defect, P3)

Description

[Johan Leuenberger]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36

Steps to reproduce:

I am trying to render a transparent web view on top of another Android view (in my case, a camera view).

In my layout, I have put a camera view and a GeckoView on top of it.
I have set the view to be transparent. See code snippet below:
geckoView.setBackgroundColor(Color.TRANSPARENT)
session.open(runtime)
geckoView.setSession(session)
geckoView.coverUntilFirstPaint(Color.TRANSPARENT)
session.loadUri("http://static.vidinoti.com/temp/geckoview/transparent.html")

The web page has been defined to be transparent. See following CSS:
html, body {
background-color: transparent;
}

Actual results:

The GeckoView is transparent at the beginning (thanks to geckoView.coverUntilFirstPaint(Color.TRANSPARENT)).
As soon as the HTML page loads, the background of the view is white instead of transparent.

Expected results:

The GeckoView background should remain transparent.

Comment 1

[Chris Peterson [:cpeterson]]

This will require some compositor work. We'll need something like this for AR in FxR.

Comment 2

[wsxiaoys.lh]

Confirmed the issue can be reproduce on 79.0.20200720193547

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 4

[Jamie Nicol [:jnicol]]

Do you remember what compositor work this requires, Chris? I believe webrender should clear the surface to a transparent color if the clear color was set to one (which it would be by the coverUntilFirstPaint call)

Comment 5

[Jamie Nicol [:jnicol]]

So it looks like we have (at least) a few separate issues here.

By default we create the EGL context with 24 bits, ie no alpha channel. This can overridden here to make us use an alpha channel.

SurfaceView doesn't appear to respect transparency by default either. Some stack overflow answers say you can fix this by calling setZOrderOnTop. This, however, breaks our dynamic toolbar by rendering the surface contents above the toolbar. We can instead use the TextureView GeckoView backend, but that has a performance cost. To do so, we must additionally call mTextureView.setOpaque(false).

With these, about:blank now renders transparent. However, loading the above URL still results in a white background. Looking at the display list I can see that the SolidColor and CanvasBackgroundColor display items (from the Viewport and Canvas(html) frames respectively) have an opaque white background. I'm not sure where exactly that gets set.

Comment 6

[Jamie Nicol [:jnicol]]

On the last point, Emilio has informed me that root content documents are deliberately opaque by default. However, we support a transparent="true" field on <xul:browser>s, so perhaps geckoview could add an API which allows an embedder to opt in to using that.

Comment 7

[Chris Peterson [:cpeterson]]

(In reply to Jamie Nicol [:jnicol] from comment #4)

Do you remember what compositor work this requires, Chris? I believe webrender should clear the surface to a transparent color if the clear color was set to one (which it would be by the coverUntilFirstPaint call)

Sorry, I don't know. This bug seems like a very low priority. Fenix doesn't need this functionality.

@ Agi, do we care about supporting apps that want to use a transparent GeckoView on top of another Android view?

Comment 8

[Jamie Nicol [:jnicol]]

Yeah, agreed this is low priority. Was asked a question about it on Matrix so just did a very brief initial investigation, in the off chance there was a trivial solution

Comment 9

[[ex-Mozilla] Agi Sferro | :agi]

This is not used by Fenix so for us is an automatic P3-at-best. We would accept patches if somebody is interested in this feature.