2011219 - browser content transparency is broken since bug 2004464

Status: RESOLVED FIXED

(Firefox :: Theme, defect)

Description

[MrOtherGuy]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:149.0) Gecko/20100101 Firefox/149.0

Steps to reproduce:

With userChrome.css and userContent.css apply the following styles:

/* userChrome.css */
#browser,
#tabbrowser-tabpanels,
.browserContainer{
  background: transparent !important;
}

and

/* userContent.css */
#preferences-root{
  background: transparent !important;
}

Actual results:

Page background on about:preferences is opaque

Expected results:

Page background on about:preferences is transparent to desktop.

Running mozregression narrowed regression range to https://hg-edge.mozilla.org/integration/autoland/rev/d7a977a1fd03fc0aa73577a7943dd78de505f2c9

Comment 1

[MrOtherGuy]

If you manually add transparent="true" attribute to the <browser> element, then the page does become transparent again.

Comment 2

[MrOtherGuy]

Should have mentioned in STR: but browser.tabs.allow_transparent_browser needs to be set to true, and it was so during my mozregression run.

Comment 3

[Robert Longson [:longsonr]]

I'm afraid we don't provide support for userChrome.css or userContent.css customization issues. Your best bet is to use the Browser Toolbox to try to debug this, or to work with other users who customize their Firefox with userChrome.css to try to debug the issue. Last I checked, the community at https://reddit.com/r/FirefoxCSS was fairly good at this, but it's been a few years.

Comment 4

[MrOtherGuy]

Fair, but the issue isn't really about custom css, it was simply the most convenient way to demonstrate this. Before 2004464 the user could set browser.tabs.allow_transparent_browser the <browser> could then become transparent to whatever was behind it - be it the xul/xhtml window or even desktop if the window itself also was transparent. Now it cannot, except if transparent="true" is manually set to the browser element. Since the linked bug touched how the attribute and the mentioned prefs are resolved and handled, then it appears to me that the new logic is flawed. That is unless the intended behavior is indeed that only AI windows should be able to respect the pref.

Comment 5

[Robert Longson [:longsonr]]

If you can demonstrate this is an issue without using custom userChrome.css or userContent.css we can reopen the bug, although you should note that bugs involving custom pref settings are generally very low priority.

Comment 6

[MrOtherGuy]

Sure.

1. Enable the built-in dark theme (built-in auto would work, but if you happen to have light system theme then you won't perceive the issue)
2. Set browser.tabs.allow_transparent_browser to false
3. Open new window, and navigate to data:text/html;base64,PGh0bWw+PGJvZHk+dGVzdDwvYm9keT48L2h0bWw+
4. Background is white as is html default
5. Close that window
6. Set browser.tabs.allow_transparent_browser to true
7. Open new window and navigate to the url above

Before bug 2004464, the browser area background was now dark-ish grey, as which is background from the Firefox built-in dark theme.
After bug 2004464, the browser area background is still white, as if browser.tabs.allow_transparent_browser is not respected.

Comment 7

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

:mlucks, since you are the author of the regressor, bug 2004464, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 9

[Monica Chiorean]

Following the steps from comment #6 I was able to reproduce the issue (meaning that the browser area background is still white on new window) on Win11x64 using Firefox builds 148.0b4 and 149.0a1(20260120100102).

Comment 10

[Monica Chiorean]

Marking issue as new.

Comment 11

[mlucks]

Attachment: Bug 2011219 - Target correct object for browser transparency attribute - r?gijs,sthompson

Comment 12

[mlucks]

Thank you for catching @MrOtherGuy fix should be landing soon

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/167cb9da04c9
https://hg.mozilla.org/integration/autoland/rev/6ac3344ac810
Target correct object for browser transparency attribute - r=tabbrowser-reviewers,sthompson DONTBUILD

Comment 14

[Ignacy Tomczyk]

I can confirm this happens to me too.

Comment 15

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/6ac3344ac810

Comment 16

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

The patch landed in nightly and beta is affected.
:mlucks, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox148 to wontfix.

For more information, please visit BugBot documentation.

Comment 17

[mlucks]

Uplift request made

Comment 18

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Potentially interfere with UI for those using transparent browser
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: I would think low, unsure how many users are using transparent windows.
• String changes made/needed: None
• Is Android affected?: no

Comment 19

[mlucks]

Attachment: Bug 2011219 - Target correct object for browser transparency attribute - DONTBUILD

Original Revision: https://phabricator.services.mozilla.com/D279737

Comment 20

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/4964c160802e
https://hg.mozilla.org/releases/mozilla-beta/rev/9676ae7e3859