The default bug view has changed. See this FAQ.

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

RESOLVED WORKSFORME

Status

()

Firefox
Theme
RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: nmaier, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Australis:P1])

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
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

3 years ago
Mike, do you have a clue about this one?
Blocks: 823180
Flags: needinfo?(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.
Flags: needinfo?(mconley)
Whiteboard: [Australis] → [Australis:P4]
(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.
(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.
(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

3 years ago
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

3 years ago
(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?
Flags: needinfo?(maierman)

Comment 8

3 years ago
(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.

Updated

3 years ago
Flags: needinfo?(maierman)
Whiteboard: [Australis:P4] → [Australis:P2]

Updated

3 years ago
Duplicate of this bug: 964300

Updated

3 years ago
Blocks: 940093

Comment 10

3 years ago
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.
Depends on: 930094
Duplicate of this bug: 943375
Bug 940093 proposes to expose this setting in the UI, which increases the urgency of fixing this bug.
Whiteboard: [Australis:P2] → [Australis:P1]
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?
Flags: needinfo?(maierman)
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
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

3 years ago
(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.
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).
Yes the right build works for me.
(Reporter)

Comment 19

3 years ago
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
Flags: needinfo?(maierman)
You need to log in before you can comment on or make changes to this bug.