1403951 - Browser window doesn't display when Dark/Light theme is enabled on Windows 10

Status: VERIFIED FIXED

(Firefox :: Theme, defect, P1)

Description

[Alice0775 White]

[Tracking Requested - why for this release]: Completely broken, Browser window is missing.

Reproducible : always

Steps To Reproduce:
1. Enable Light Theme from addon manager
2. Restart

Actual Results:
No browser window display. 


Expected Results:
Browser window should display properly

Comment 1

[Johann Hofmann [:johannh]]

Your STR work fine for me on Windows 10 (and OSX). Can you elaborate more and e.g. include a screenshot? Can you use mozregression to find out when this started happening for you?

Comment 2

[Alice0775 White]

(In reply to Johann Hofmann [:johannh] from comment #1)
> Your STR work fine for me on Windows 10 (and OSX). Can you elaborate more
> and e.g. include a screenshot? Can you use mozregression to find out when
> this started happening for you?

Impossible to take screenshot because no browser window display.
This is regressed by Bug 1366405

Comment 3

[Johann Hofmann [:johannh]]

(In reply to Alice0775 White from comment #2)
> (In reply to Johann Hofmann [:johannh] from comment #1)
> > Your STR work fine for me on Windows 10 (and OSX). Can you elaborate more
> > and e.g. include a screenshot? Can you use mozregression to find out when
> > this started happening for you?
> 
> Impossible to take screenshot because no browser window display.
> This is regressed by Bug 1366405

Sorry, just to confirm, this is happening when you create a fresh profile and enable the Light Theme? And only after a restart? And it doesn't happen with dark theme? And "no browser window display" means your task bar is showing Firefox as active but there's no window open?

Comment 5

[Alice0775 White]

With new profile and enable Light theme and restart.
I do not know about Dark Theme.
Taskbar button display as expected, but no browser window display.

Comment 6

[Johann Hofmann [:johannh]]

Ok, can you try dark theme please? Also, what's your Windows Theme? Are you showing accent colors in the title bar? What is your screen resolution and DPI setting?

Comment 7

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Using any theme/appearance/persona in Mozilla Firefox Nightly 58.0a1 (2017-09-28) (64-bit) on Windows 7 (64-bit) makes minimize/maximize/close buttons missing and its place it's nonoperational, so they're not only not visible or hidden, just completely removed.

Comment 8

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: bad=with Theme.png

Comment 9

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: good=without Theme.png

Comment 10

[Emanuel Hoogeveen [:ehoogeveen]]

Nothing is displayed for me either on Windows 10 using the Dark Theme.

Comment 11

[gixxpunk]

Bug Confirmed

Comment 12

[Johann Hofmann [:johannh]]

Hmm, though I still can't reproduce this, the number of people chiming in makes me think we might back out bug 1366405 if we can't find a solution quickly. Dão, any thoughts?

Comment 13

[Dão Gottwald [:dao]]

I can reproduce. Working on it.

Comment 14

[Edo Karabas]

Fuh, that's really unfortunate. There has to be some critical dependency in the code to paint a window after startup with light themes which depends on Bug 1366405. Browser itself starts, you can see it in the taskbar but without window there is nothing to do. The only workaround is to revert to the manually downloaded previous build and there change the theme.

Comment 16

[Dão Gottwald [:dao]]

Attachment: Bug 1403951 - Stop setting -moz-appearance: none; on :root for lightweight themes as it completely breaks the window when the Windows compositor is enabled.

Review commit: https://reviewboard.mozilla.org/r/184652/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/184652/

Comment 17

[Dão Gottwald [:dao]]

Comment on attachment 8913269 [details]
Bug 1403951 - Stop setting -moz-appearance: none; on :root for lightweight themes as it completely breaks the window when the Windows compositor is enabled.

https://reviewboard.mozilla.org/r/184652/#review189824

::: toolkit/themes/windows/global/global.css
(Diff revision 1)
>  
>  /* ::::: miscellaneous formatting ::::: */
>  
> -:root:-moz-lwtheme {
> -  -moz-appearance: none;
> -}

I'm not sure that this rule ever did something useful on Windows. I think we always used to override it in browser.css in the compositor case, and in the non-compositor case it seems to be a no-op (briefly checked with aero basic).

Comment 18

[Johann Hofmann [:johannh]]

Comment on attachment 8913269 [details]
Bug 1403951 - Stop setting -moz-appearance: none; on :root for lightweight themes as it completely breaks the window when the Windows compositor is enabled.

https://reviewboard.mozilla.org/r/184652/#review189826

Since you added this I trust you to remove it :)

Comment 19

[Dão Gottwald [:dao]]

try build: https://queue.taskcluster.net/v1/task/LbU-VmqeR7iWau3ANdD85w/runs/0/artifacts/public/build/target.zip

Comment 20

[Johann Hofmann [:johannh]]

Wait, while this patch is probably fine as is (since it might be a no-op), the problem isn't perfectly fixed on my local build (turns out I can reproduce it on central). The window starts up fine with lw themes, but I get weird flickering and partial transparency everwhere else.

Comment 21

[Johann Hofmann [:johannh]]

(In reply to Johann Hofmann [:johannh] from comment #20)
> Wait, while this patch is probably fine as is (since it might be a no-op),
> the problem isn't perfectly fixed on my local build (turns out I can
> reproduce it on central). The window starts up fine with lw themes, but I
> get weird flickering and partial transparency everwhere else.

Everywhere else was supposed to mean that during browsing, random elements of the browser become transparent intermittently.

Comment 22

[Johann Hofmann [:johannh]]

(Only on Windows 10)

Comment 23

[Edo Karabas]

Perhaps kind of same which Alice reported in bug 1403973 ?

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/56ca38c33b96
Stop setting -moz-appearance: none; on :root for lightweight themes as it completely breaks the window when the Windows compositor is enabled. r=johannh

Comment 25

[Edo Karabas]

(In reply to Dão Gottwald [::dao] from comment #19)
> try build:
> https://queue.taskcluster.net/v1/task/LbU-VmqeR7iWau3ANdD85w/runs/0/
> artifacts/public/build/target.zip

I don't know, but doesn't seem to fix the issue for me, browser window is still not showing up...
It is showing up with visual glitches when HWA is disabled however, but it is the same on latest Nightly

Comment 26

[Dão Gottwald [:dao]]

I think there's another problem in compacttheme.css. Investigating...

Comment 27

[Dão Gottwald [:dao]]

Attachment: Bug 1403951 - Dark/Light themes shouldn't make the window transparent on Windows 10.

Review commit: https://reviewboard.mozilla.org/r/184676/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/184676/

Comment 28

[Hal Wine [:hwine] use NI!]

seeing this on win10 with latest nightly (can't get version number, because no windows)

Comment 30

[alex_mayorga]

¡Hola Pascal!

Removed the theme reference as this bite me on the dark theme as well...

Shall we tweet something from @FirefoxNightly?

¡Gracias!
Alex

Comment 31

[Kuzma Fesenko]

I was using the dark theme when my Nightly updated and the application window would not show. Pressing F11 twice does allow the window to show though.

Starting nightly with a new profile fixes the problem entirely for me.

Comment 32

[Dão Gottwald [:dao]]

Try build with both fixes: https://queue.taskcluster.net/v1/task/W5QhP09lQWSRzVzNCpRy-Q/runs/0/artifacts/public/build/target.zip

Comment 33

[Kuzma Fesenko]

(In reply to Dão Gottwald [::dao] from comment #32)
> Try build with both fixes:
> https://queue.taskcluster.net/v1/task/W5QhP09lQWSRzVzNCpRy-Q/runs/0/
> artifacts/public/build/target.zip

Works for me!

Comment 34

[Johann Hofmann [:johannh]]

Comment on attachment 8913305 [details]
Bug 1403951 - Dark/Light themes shouldn't make the window transparent on Windows 10.

https://reviewboard.mozilla.org/r/184676/#review189850

Fixes the problem for me, but I'd appreciate an explanation of the change :)

Comment 35

[Ryan VanderMeulen [:RyanVM]]

I backed out bug 1366405 from m-c to make sure that this is fixed in the next round of Nightlies that we build later today. I'm happy to re-land it for you once the fixes from this bug hit autoland, Dao. Just let me know :)

https://hg.mozilla.org/mozilla-central/rev/3177c1b64ffe7ba5c08851791bd495421dcedb05

Comment 36

[Mozilla Autoland]

We're sorry - something has gone wrong while rewriting or rebasing your commits. The commits being pushed no longer match what was requested. Please file a bug.

Comment 37

[Pascal Chevrel:pascalc]

(In reply to alex_mayorga from comment #30)
> ¡Hola Pascal!
> 
> Removed the theme reference as this bite me on the dark theme as well...
> 
> Shall we tweet something from @FirefoxNightly?
> 
> ¡Gracias!
> Alex

This is done, first 280 tweet + I recorded a video tutorial showing how to restart in safe mode and reset the theme to default https://twitter.com/FirefoxNightly/status/913452861161385986

Comment 38

[Edo Karabas]

(In reply to Dão Gottwald [::dao] from comment #32)
> Try build with both fixes:
> https://queue.taskcluster.net/v1/task/W5QhP09lQWSRzVzNCpRy-Q/runs/0/
> artifacts/public/build/target.zip

Fixed all issues for me, browser is launching fine.
One minor glitch however appears. Top browser border with light theme is white. There is no such problem with a dark theme or default theme.
See https://s26.postimg.org/sr1zn6o5l/border.png

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1b728c9c1f45
Dark/Light themes shouldn't make the window transparent on Windows 10. r=johannh

Comment 41

[Nate Over]

If it's of any use, this also seems to affect Windows 7, and for my Windows 7 system on an i5-2400 iGPU, disabling hardware acceleration causes the browser to display, but window borders are missing and there is no animation upon dragging the window by the tab header (using Dark/Light theme of course).

Comment 42

[Dão Gottwald [:dao]]

(In reply to Nate Over from comment #41)
> If it's of any use, this also seems to affect Windows 7, and for my Windows
> 7 system on an i5-2400 iGPU, disabling hardware acceleration causes the
> browser to display, but window borders are missing and there is no animation
> upon dragging the window by the tab header (using Dark/Light theme of
> course).

Does it work with <https://queue.taskcluster.net/v1/task/W5QhP09lQWSRzVzNCpRy-Q/runs/0/artifacts/public/build/target.zip>? If not, could you please file a new bug?

Comment 43

[Nate Over]

(In reply to Dão Gottwald [::dao] from comment #42)
> (In reply to Nate Over from comment #41)
> > If it's of any use, this also seems to affect Windows 7, and for my Windows
> > 7 system on an i5-2400 iGPU, disabling hardware acceleration causes the
> > browser to display, but window borders are missing and there is no animation
> > upon dragging the window by the tab header (using Dark/Light theme of
> > course).
> 
> Does it work with
> <https://queue.taskcluster.net/v1/task/W5QhP09lQWSRzVzNCpRy-Q/runs/0/
> artifacts/public/build/target.zip>? If not, could you please file a new bug?

It's fixed with that, thank you! But are you able to elaborate? Is the official Win64 download not developed with Windows 7 in mind? What was different about what you provided from what's default? I'm new to this so I apologize for anything that should be obvious. Thanks again.

Comment 44

[Edo Karabas]

It is developed with Win 7 in mind, but bug 1366405 introduced some side effects, which are being fixed in this bug. Dao just pointed you to the build which included fixes from this bug, which will be eventually available for everyone in the next Nightly or the one after that.

Comment 45

[Nate Over]

(In reply to Eddward from comment #44)
> It is developed with Win 7 in mind, but bug 1366405 introduced some side
> effects, which are being fixed in this bug. Dao just pointed you to the
> build which included fixes from this bug, which will be eventually available
> for everyone in the next Nightly or the one after that.

Ah, I see. That makes sense. One other thing - it shows my Nightly build is now on the default update channel rather than the nightly one. What's this about? I'll still receive the nightly updates, or won't I?

Comment 46

[Edo Karabas]

Your regular Nightly build should be on the Nightly update channel. Default update channel are usually for developer builds such as the one provided by Dao.

Comment 47

[Nate Over]

Okay, so default means something other than I expected. Thank you.

Comment 48

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/56ca38c33b96
https://hg.mozilla.org/mozilla-central/rev/1b728c9c1f45

Comment 49

[Clément Lefèvre]

By the way, I experienced same symptoms on Windows 7, but only with Aero theme (basic and classic are not affected).
I'll check with those fixes with tomorrow's build to be sure if this was the same cause and same effects of not.

Comment 50

[Ed Morley [:emorley]]

Is there test coverage that could be added that would have caught this?

Comment 51

[Dão Gottwald [:dao]]

(In reply to Ed Morley [:emorley] from comment #50)
> Is there test coverage that could be added that would have caught this?

No.

Comment 52

[Sean Smith]

After today's update I was using the "Mightly" lightweight theme.  When I restarted, the window did not show up.

After getting back to a usable state, I went to Add-ons -> Themes, and enabled some of my other lightweight themes.  I have found that some themes turn the window frame white, and those themes will render the invisible window on Nightly restart.

Some of those themes:
https://addons.mozilla.org/en-US/firefox/addon/abstracblue/
https://addons.mozilla.org/en-US/firefox/addon/aurora-australis/
https://addons.mozilla.org/en-US/firefox/addon/blue-bomb/
https://addons.mozilla.org/en-US/firefox/addon/frozen-wood/
https://addons.mozilla.org/en-US/firefox/addon/nightly/

I am using build ID 20170929100122

Comment 53

[Mike Conley (:mconley) (:⚙️)]

(In reply to Dão Gottwald [::dao] from comment #51)
> (In reply to Ed Morley [:emorley] from comment #50)
> > Is there test coverage that could be added that would have caught this?
> 
> No.

Shouldn't mozscreenshots have caught this?

Comment 54

[Dão Gottwald [:dao]]

(In reply to Sean Smith from comment #52)
> After today's update I was using the "Mightly" lightweight theme.  When I
> restarted, the window did not show up.
> 
> After getting back to a usable state, I went to Add-ons -> Themes, and
> enabled some of my other lightweight themes.  I have found that some themes
> turn the window frame white, and those themes will render the invisible
> window on Nightly restart.

Can you please file a new bug?

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #53)
> (In reply to Dão Gottwald [::dao] from comment #51)
> > (In reply to Ed Morley [:emorley] from comment #50)
> > > Is there test coverage that could be added that would have caught this?
> > 
> > No.
> 
> Shouldn't mozscreenshots have caught this?

I'm not sure if this kind of rendering quirk is visible to mozscreenshots, but either way -- we don't have automatic mozscreenshots alerts.

Comment 55

[Sean Smith]

(In reply to Dão Gottwald [::dao] from comment #54)
> (In reply to Sean Smith from comment #52)
> > After today's update I was using the "Mightly" lightweight theme.  When I
> > restarted, the window did not show up.
> > 
> > After getting back to a usable state, I went to Add-ons -> Themes, and
> > enabled some of my other lightweight themes.  I have found that some themes
> > turn the window frame white, and those themes will render the invisible
> > window on Nightly restart.
> 
> Can you please file a new bug?
> 
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1404386

Thanks.

Comment 58

[Dão Gottwald [:dao]]

https://hg.mozilla.org/releases/mozilla-beta/rev/7c374b1db6da

Comment 59

[roxleitan]

Tested on Mac OS X 10.12, Ubuntu 16.04 x64 and Windows 10 x64 using a Nightly build from 2017-09-28 and reproduced the initial issue(from the description) only on Windows 10 x64.

Verified as fixed using the latest Nightly 58.0a1 (Build ID: 20171005220204) on Windows 10 x64.
Verified also on Ubuntu 16.04 and Mac 10.12 with the latest Nightly 58.0a1.

Comment 60

[Ciprian Georgiu, Desktop QA]

I managed to repro this issue using an affected Nightly build (2017-09-28) with STR from comment 0.

This is also verified fixed on Beta 57.0b6 (20171005195903) under Windows 10 x64.

Comment 61

[Matthew N. [:MattN]]

(In reply to Dão Gottwald [::dao] from comment #54)
> (In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from
> comment #53)
> > (In reply to Dão Gottwald [::dao] from comment #51)
> > > (In reply to Ed Morley [:emorley] from comment #50)
> > > > Is there test coverage that could be added that would have caught this?
> > > 
> > > No.
> > 
> > Shouldn't mozscreenshots have caught this?

It may have if buildbot limitations didn't cause bug 1329262 to get backed out. Now that we fully switched mozscreenshots to TaskCluster I've relanded bug 1329262 so it could get caught in the future.

> I'm not sure if this kind of rendering quirk is visible to mozscreenshots,
> but either way -- we don't have automatic mozscreenshots alerts.

We do have automatic mozscreenshots alerts going to the dev-ui-alerts list (https://www.mozilla.org/en-US/about/forums/#dev-ui-alerts) but I haven't publicized it widely since there are intermittent failures. Johann and I are the main ones who look at it though to triage and I haven't had time recently.

Comment 62

[Dão Gottwald [:dao]]

(In reply to Matthew N. [:MattN] (PM if requests are blocking you) from comment #61)
> > I'm not sure if this kind of rendering quirk is visible to mozscreenshots,
> > but either way -- we don't have automatic mozscreenshots alerts.
> 
> We do have automatic mozscreenshots alerts going to the dev-ui-alerts list
> (https://www.mozilla.org/en-US/about/forums/#dev-ui-alerts) but I haven't
> publicized it widely since there are intermittent failures. Johann and I are
> the main ones who look at it though to triage and I haven't had time
> recently.

That's not quite as automatic as I meant, though. It's from mozilla-central and likely wouldn't have prevented this from hitting Nightly.