941831 - On OSX, after Australis customization, with browser.tabs.drawInTitlebar=false, the window gets incorrectly drawn

Status: RESOLVED WORKSFORME

(Firefox :: Theme, defect)

Description

[Nils Maier [:nmaier]]

Attachment: Screen shot

STR:
- Set browser.tabs.drawInTitlebar to true
- Go into Customize by any means
- Exit Customize

Result:
The tabs get drawn into the titlebar again, but without the padding and margins to make it not overlap with the window buttons.

Excepted:
Window should look like before customization.

If browser.tabs.drawInTitlebar isn't supposed to be supported anymore, however, the pref shouldn't be processed anymore.

Latest Nightly on OSX Lion.
Built from http://hg.mozilla.org/mozilla-central/rev/cf378dddfac8

Comment 1

[:Gijs (he/him)]

Mike, do you have a clue about this one?

Comment 2

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

For the foreseeable future, browser.tabs.drawInTitlebar is still going to be supported.

I have a vague idea that this might have to do with our TabsInTitlebar code doing something silly, but it will require a closer look.

Comment 3

[Matthew N. [:MattN]]

(In reply to Mike Conley (:mconley) from comment #2)
> For the foreseeable future, browser.tabs.drawInTitlebar is still going to be
> supported.

This is a change in decision. We weren't planning on supporting it for OS X. Has the influx of feedback caused us to change our mind? Extensions can fix these issues to support this pref if needed. I don't think we need to jump to fix this right away.

Comment 4

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

(In reply to Matthew N. [:MattN] (catching up on reviews) from comment #3)
> (In reply to Mike Conley (:mconley) from comment #2)
> > For the foreseeable future, browser.tabs.drawInTitlebar is still going to be
> > supported.
> 
> This is a change in decision. We weren't planning on supporting it for OS X.
> Has the influx of feedback caused us to change our mind? Extensions can fix
> these issues to support this pref if needed. I don't think we need to jump
> to fix this right away.

I'd heard rumblings from shorlander of maybe even exposing it more in the UI, but I guess this is all hearsay.

Comment 5

[Stephen Horlander [:shorlander]]

(In reply to Mike Conley (:mconley) from comment #4)
> (In reply to Matthew N. [:MattN] (catching up on reviews) from comment #3)
> > (In reply to Mike Conley (:mconley) from comment #2)
> > > For the foreseeable future, browser.tabs.drawInTitlebar is still going to be
> > > supported.
> > 
> > This is a change in decision. We weren't planning on supporting it for OS X.
> > Has the influx of feedback caused us to change our mind? Extensions can fix
> > these issues to support this pref if needed. I don't think we need to jump
> > to fix this right away.
> 
> I'd heard rumblings from shorlander of maybe even exposing it more in the
> UI, but I guess this is all hearsay.

It is currently one of the issues we have been hearing a lot about. So something to discuss, but not something we make a knee jerk reaction on.

Comment 6

[Armin Ronacher]

Please continue supporting it in OS X.  For people with tons of tabs open it's a life saver because you can't otherwise read the title bar.

Comment 7

[:Gijs (he/him)]

(In reply to Nils Maier [:nmaier] from comment #0)
> Created attachment 8336305 [details]
> Screen shot
> 
> STR:
> - Set browser.tabs.drawInTitlebar to true

The summary says 'false'. Which is it?

Comment 8

[Avi Halachmi (:avih)]

(In reply to :Gijs Kruitbosch from comment #7)
> The summary says 'false'. Which is it?

I think the title is correct. I can reproduce the bug with 'false' which is the non-default setup right now. With 'true' there's no such issue AFAICT.

As a temporary workaround, the pref could be set to true and then back to false, and the layout straightens out afterwards, no restart required.

Comment 10

[:Gijs (he/him)]

As far as I can tell, this is caused by the same issue as bug 930094. When exiting customize mode, the LWT-consumer is re-enabled, and it re-sets the chrome margin. That causes things to go wrong.

Comment 12

[Jonathan Kew [:jfkthame]]

Bug 940093 proposes to expose this setting in the UI, which increases the urgency of fixing this bug.

Comment 13

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

The patch in bug 930094 should hopefully address this. Assuming all goes well on fx-team, this should hopefully hit tomorrow's Nightly, and then perhaps you can test this again nmaier?

Comment 14

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

Now that bug 930094 has landed on Nightly, I'm unable to reproduce this on OS X Mountain Lion or Snow Leopard.

Marking WORKSFORME, unless the reporter is still able to reproduce with a recent Nightly.

Comment 15

[Yeuk Hon Wong [:yeukhon]]

Attachment: screenshot-after-resolve.jpg

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140205030203 CSet: 1f170f9fead0

1. Quit Firefox
2. Open Firefox
3. Click customization
4. click exit customization


Tested with and without external monitor.

Comment 16

[:Gijs (he/him)]

(In reply to Yeuk Hon Wong [:yeukhon] from comment #15)
> Created attachment 8370899 [details]
> screenshot-after-resolve.jpg
> 
> Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101
> Firefox/30.0 ID:20140205030203 CSet: 1f170f9fead0

That build doesn't have the fix yet.

Comment 17

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

Yeah, my mistake - this fix has not yet been rolled into a Nightly release. It missed the cut-off by a few hours. It should be in tomorrow's Nightly (Feb 6).

Comment 18

[Yeuk Hon Wong [:yeukhon]]

Yes the right build works for me.

Comment 19

[Nils Maier [:nmaier]]

Yeah, works for me with the latest nightly. Thanks Mike.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:30.0) Gecko/20100101 Firefox/30.0
Built from https://hg.mozilla.org/mozilla-central/rev/1e9f169c9715