Dan Callahan [:callahad] Reporter
	Description • 7 years ago

See screenshot

Steps to reproduce:

1. Launch Firefox 53
2. Menu -> Customize -> Theme -> Compact Dark
3. Menu -> Customize -> Title Bar (enabled)
4. Open a new window

Expected Results:

- The window's title bar matches the color of the dark theme (#272B35)
- The window title is visible and legible

Actual Results:

- The window's title bar is pitch black (#000000)
- The window title is not visible

	Dan Callahan [:callahad] Reporter
	Comment 1 • 7 years ago

(Reported to me by @blakkheim on Twitter)

	Jeff Griffiths (:canuckistani) (:⚡︎)
	Comment 2 • 7 years ago

Huh - I can't repro maybe there's something I'm missing. I'm running macOS 10.12.4, see both nightly 55 ( background ) and release 53 ( foreground )

	Dan Callahan [:callahad] Reporter
	Comment 3 • 7 years ago

It's a bit large for an attachment, but I've recorded myself repro'ing on macOS 10.12.4 using Firefox 53.0. The same thing happens for me in Nightly.

Screencast at https://people-mozilla.org/~dcallahan/tmp/Bug1357892.mp4

	:Gijs (he/him)
	Comment 4 • 7 years ago

Maybe this is a graphics issue? Dan, if you turn off graphics acceleration, do you see the same thing? What machine are you testing on? (same question for Jeff)

	Dan Callahan [:callahad] Reporter
	Comment 5 • 7 years ago

I still see the same bug after disabling hardware acceleration and restarting the browser. Preferences changed:

  - Preferences -> Advanced -> General -> Use Hardware Acceleration when Available (unchecked)
  - Set gfx.canvas.azure.accelerated to false
  - Set layers.acceleration.disabled to true

I restarted the browser after applying those settings.

I'm on an Early 2015 13" MacBook Pro (MacBookPro12,1). It has a 3.1 GHz i7 with an integrated Intel Iris 6100 GPU.

I see the bug with the laptop on its own, and with the laptop in closed and connected to an external, normal dpi monitor.

There's nothing obvious in the browser console.

If I launch from the terminal, I so see some error spew when I spawn a new window, but I see that regardless of theme, so it's probably a red herring:

2017-04-19 21:08:11.454 plugin-container[5240:1157666] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x983b, name = 'com.apple.tsm.portname'
See /usr/include/servers/bootstrap_defs.h for the error codes.
2017-04-19 21:08:11.454 plugin-container[5240:1157666] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x9b03, name = 'com.apple.CFPasteboardClient'
See /usr/include/servers/bootstrap_defs.h for the error codes.

	Mike Conley (:mconley) (:⚙️)
	Comment 6 • 7 years ago

I can reproduce this using callahad's steps.

The initial window, where we change the theme and toggle the titlebar, does not have a chromemargin attribute set on the <window> element.

The new window, however, has chromemargin="0,-1,-1,-1" set on it, meaning that we're telling Gecko "We're going to paint the titlebar, don't worry about it".

What is this theme supposed to look like with the titlebar enabled? Are we supposed to be using the native titlebar, or painting our own?

	:Gijs (he/him)
	Comment 7 • 7 years ago

(In reply to Mike Conley (:mconley) from comment #6)
> I can reproduce this using callahad's steps.
> 
> The initial window, where we change the theme and toggle the titlebar, does
> not have a chromemargin attribute set on the <window> element.
> 
> The new window, however, has chromemargin="0,-1,-1,-1" set on it, meaning
> that we're telling Gecko "We're going to paint the titlebar, don't worry
> about it".
> 
> What is this theme supposed to look like with the titlebar enabled? Are we
> supposed to be using the native titlebar, or painting our own?

Whatever we normally do for lightweight themes.

	Brian Grinstead [:bgrins]
	Comment 8 • 7 years ago

(In reply to :Gijs from comment #7)
> (In reply to Mike Conley (:mconley) from comment #6)
> > I can reproduce this using callahad's steps.
> > 
> > The initial window, where we change the theme and toggle the titlebar, does
> > not have a chromemargin attribute set on the <window> element.
> > 
> > The new window, however, has chromemargin="0,-1,-1,-1" set on it, meaning
> > that we're telling Gecko "We're going to paint the titlebar, don't worry
> > about it".
> > 
> > What is this theme supposed to look like with the titlebar enabled? Are we
> > supposed to be using the native titlebar, or painting our own?
> 
> Whatever we normally do for lightweight themes.

I agree - the compact theme behavior shouldn't be different from a dark lw theme (for instance, Space Fantasy - which is available in customize mode as well).  I see some weird behavior generally enabling title bar and lightweight themes from customize mode.  Like these two lead to slightly different bad effects:

CASE A:
1. Menu -> Customize -> Title Bar (enabled)
2. Menu -> Customize -> Theme -> Space Fantasy
3. Exit customize mode: Titlebar isn't visible but title is still centered
4. Open new window: Titlebar isn't visible but title is still centered

CASE B:
1. Menu -> Customize -> Theme -> Space Fantasy
2. Menu -> Customize -> Title Bar (enabled)
3. Exit customize mode: Titlebar works now
4. Open new window: Titlebar isn't visible

Note that B is working OK at step 3 but reverts to the same behavior in step 4.

If I shuffle through steps 1 and 2 in customize mode a few times I'm eventually able to reproduce the black titlebar issue.  Maybe customize mode is leaving the window in a bad state when combining titlebar changes and lightweight theme previews / changes?

	Brian Grinstead [:bgrins]
	Comment 9 • 7 years ago

Example from Comment 8 for "Titlebar isn't visible but title is still centered"

	:Gijs (he/him)
	Comment 10 • 7 years ago

Can someone try to find a regression window for this with mozregression (I'm away from my main internet connection over the rest of today, making it tricky to download lots of builds)? I'm pretty sure this used to work properly (esp. the general lwt case, I remember mconley slaving away on that stuff in the Australis timeframe). I don't think this is specific to the compact themes, and so maybe a regression window will help narrow down why/how this is breaking.

	Dan Callahan [:callahad] Reporter
	Comment 11 • 7 years ago

I manually downloaded a bunch of Aurora builds. I'm not sure this *ever* worked properly.

For what it's worth, on macOS 10.12.4:

- Aurora 39 and older don't seem to run.
- Aurora 40-52 fail with a flat white title bar. (Last buildid: 20170123004004)
- Aurora 53 and later fail with a flat black title bar. (First buildid: 20170123080355)

Hrmph.

	Dan Callahan [:callahad] Reporter
	Comment 12 • 7 years ago

(Which is to say: We could try to find a regression window in 53 when it transitioned from failing white to failing black, but *both* are failing. Instead, we should probably extend the theme's color into the titlebar, like we do with lightweight themes.)

	Jeff Griffiths (:canuckistani) (:⚡︎)
	Comment 13 • 7 years ago

What I really want, for dark themes, is a dark titlebar with visible text. The colour we set for the daark titlebar should be from the theme. 

I think the light/mid grey titlebar you see in the main window is not good. I think the black titlebar is better but what I really want for all windows with the titlebar visible and the compact dark theme enabled is a titlebar that uses the dark theme's colour and has visible ( white or ~ #efefef ) text.

	Dão Gottwald [:dao]
	Comment 15 • 7 years ago

Is this still an issue?