Last Comment Bug 941831 - On OSX, after Australis customization, with browser.tabs.drawInTitlebar=false, the window gets incorrectly drawn
: On OSX, after Australis customization, with browser.tabs.drawInTitlebar=false...
Status: RESOLVED WORKSFORME
[Australis:P1]
:
Product: Firefox
Classification: Client Software
Component: Theme (show other bugs)
: unspecified
: All Mac OS X
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Dão Gottwald [:dao]
Mentors:
: 943375 964300 (view as bug list)
Depends on: 930094
Blocks: australis-merge australis-tabs-osx 940093
  Show dependency treegraph
 
Reported: 2013-11-21 12:04 PST by Nils Maier [:nmaier]
Modified: 2014-02-06 09:42 PST (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screen shot (15.97 KB, image/png)
2013-11-21 12:04 PST, Nils Maier [:nmaier]
no flags Details
screenshot-after-resolve.jpg (1.15 MB, image/jpeg)
2014-02-05 10:58 PST, Yeuk Hon Wong [:yeukhon]
no flags Details

Description User image Nils Maier [:nmaier] 2013-11-21 12:04:31 PST
Created attachment 8336305 [details]
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 User image :Gijs 2013-11-21 12:08:07 PST
Mike, do you have a clue about this one?
Comment 2 User image Mike Conley (:mconley) 2013-11-21 13:47:09 PST
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 User image Matthew N. [:MattN] (PM if requests are blocking you) 2013-11-21 13:59:46 PST
(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 User image Mike Conley (:mconley) 2013-11-21 16:05:18 PST
(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 User image Stephen Horlander [:shorlander] 2013-11-21 16:07:28 PST
(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 User image Armin Ronacher 2013-12-13 04:05:19 PST
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 User image :Gijs 2014-01-20 05:02:58 PST
(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 User image Avi Halachmi (:avih) 2014-01-20 05:30:54 PST
(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 9 User image :Gijs 2014-01-28 04:51:41 PST
*** Bug 964300 has been marked as a duplicate of this bug. ***
Comment 10 User image :Gijs 2014-01-28 05:12:30 PST
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 11 User image Jonathan Kew (:jfkthame) 2014-01-28 13:27:23 PST
*** Bug 943375 has been marked as a duplicate of this bug. ***
Comment 12 User image Jonathan Kew (:jfkthame) 2014-01-28 13:29:35 PST
Bug 940093 proposes to expose this setting in the UI, which increases the urgency of fixing this bug.
Comment 13 User image Mike Conley (:mconley) 2014-02-04 14:36:15 PST
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 User image Mike Conley (:mconley) 2014-02-05 10:37:18 PST
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 User image Yeuk Hon Wong [:yeukhon] 2014-02-05 10:58:16 PST
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

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


Tested with and without external monitor.
Comment 16 User image :Gijs 2014-02-05 11:01:11 PST
(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 User image Mike Conley (:mconley) 2014-02-05 11:05:33 PST
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 User image Yeuk Hon Wong [:yeukhon] 2014-02-05 11:09:45 PST
Yes the right build works for me.
Comment 19 User image Nils Maier [:nmaier] 2014-02-06 09:42:17 PST
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

Note You need to log in before you can comment on or make changes to this bug.