576394 - Startup always loads titlebar above firefox menu button and does not start in drawing in titlebar mode

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[[not reading bugmail]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100701 Minefield/4.0b2pre Firefox/3.6.6
Build Identifier: 

Drawing in the titlebar doesn't initialized on startup.. Firefox Menu is under the titlebar, the double clicking on glass is the behavior like the menubar is showing instead.

Works:
http://hg.mozilla.org/mozilla-central/rev/e6ef4a34b9e1

broken:
http://hg.mozilla.org/mozilla-central/rev/8425474fc441

Candidate: bug 573973 or bug 572680

Reproducible: Always

Steps to Reproduce:
Turn on menubar, turn off menubar, fixes it, restart browser..
Actual Results:  
Startup affected, titlebar is always displayed as a regular window mode, not custom drawing in the titlebar mode.

Expected Results:  
Should startup with previous configuration and/or drawing in the titlebar first with app menu in titlebar not below it.

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

Confrimed, setting to New

Comment 2

[Jim Jeffery not reading bug-mail 1/2/11]

When doing the STR above, I now see a large gap between the status bar and the Win7 TaskBar...  About the distance that would be consumed by the Menu+Titlebar

Minimizing/Maximizing the browser fills the gap.

Comment 3

[[not reading bugmail]]

(In reply to comment #2)
> When doing the STR above, I now see a large gap between the status bar and the
> Win7 TaskBar...  About the distance that would be consumed by the Menu+Titlebar
> 
> Minimizing/Maximizing the browser fills the gap.

I believe that's bug 575005

Comment 4

[pal-moz]

(In reply to comment #3)
> (In reply to comment #2)
> > When doing the STR above, I now see a large gap between the status bar and the
> > Win7 TaskBar...  About the distance that would be consumed by the Menu+Titlebar
> > 
> > Minimizing/Maximizing the browser fills the gap.
> 
> I believe that's bug 575005

maybe different bug.

Comment 5

[imradyurrad]

This bug is so annoying. Anybody know what caused it?

Comment 6

[Jim Mathies [:jimm]]

Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100701 Firefox/3.6.4 ( .NET CLR 3.5.30729; .NET4.0C)

What are the STR? I'm unable to reproduce.

Comment 7

[imradyurrad]

(In reply to comment #6)
> Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre)
> Gecko/20100701 Firefox/3.6.4 ( .NET CLR 3.5.30729; .NET4.0C)
> 
> What are the STR? I'm unable to reproduce.

With the latest hourly/nightly, have the menubar disabled and restart firefox.

Comment 8

[imradyurrad]

Attachment: screenshot

Comment 9

[Markus Stange [:mstange]]

Oops, I didn't realize that SetDrawsInTitlebar is now also implemented on Windows. What seems to happen is that further up in that function in nsXULWindow.cpp, when the "chromemargin" attribute is processed, the margins get set correctly, but then when the "drawintitlebar" attribute isn't present, the margins get unset again.

Jim, why did you implement SetDrawsInTitlebar on Windows? Is it used?

Comment 10

[[not reading bugmail]]

(In reply to comment #6)
> Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre)
> Gecko/20100701 Firefox/3.6.4 ( .NET CLR 3.5.30729; .NET4.0C)
> 
> What are the STR? I'm unable to reproduce.

Yeah, the standard bug filer takes my UA string and it would be in tomorrow's nightly.  Thanks Taz.  I was going to add the pushlog range earlier but didn't have time.

Comment 11

[Markus Stange [:mstange]]

Fixed by backout of bug 573973.

Comment 12

[imradyurrad]

(In reply to comment #11)
> Fixed by backout of bug 573973.

=] fast.

Comment 13

[Jim Mathies [:jimm]]

(In reply to comment #9)
> Oops, I didn't realize that SetDrawsInTitlebar is now also implemented on
> Windows. What seems to happen is that further up in that function in
> nsXULWindow.cpp, when the "chromemargin" attribute is processed, the margins
> get set correctly, but then when the "drawintitlebar" attribute isn't present,
> the margins get unset again.
> 
> Jim, why did you implement SetDrawsInTitlebar on Windows? Is it used?

It's implemented. It calls the non client margins setup call with the titlebar turned off and all the other margins turned on.

We can unhook it, but it seemed a good idea to support it on windows now that we can, as it's defined in the main widget interface.