574859 - Right-clicking the new title bar does not bring up the system menu

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Shayne Jewers]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100625 Minefield/3.7a6pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100625 Minefield/3.7a6pre ID:20100625132647

When right-clicking the new title bar (bug 513162), the title bar context menu does not appear.

Reproducible: Always

Steps to Reproduce:
1.Right click the title bar.
2.
3.
Actual Results:  
The title bar context menu does not appear

Expected Results:  
The title bar context menu should appear

Comment 1

[Jim Mathies [:jimm]]

This is be address by the content hit testing code.

Comment 2

[:Felipe Gomes (needinfo for replies!)]

Our own context menus already work now with the new hit test, so I'll morph this a little bit to specifically cover the system menu.

Comment 6

[imradyurrad]

I see a potential regression in that the whole glass area will be effected by this.

Comment 7

[abittner]

related question: how do you actually bring up the normal classic menu bar without the help of a keyboard by pressing the "alt" key there? i havent found any way to navigate to the classic menus without a keyboard.

Comment 8

[[not reading bugmail]]

(In reply to comment #7)
> how do you actually bring up the normal classic menu bar

Firefox menu->Customize->Menu Bar

This bug is about the system context menu not showing in the titlebar with the new firefox app menu button, not the menu bar.

(In reply to comment #6)
> I see a potential regression in that the whole glass area will be effected by
> this.

Each toolbar has their own context menu.  The rest of the toolbars currently work with glass.

Comment 9

[imradyurrad]

> (In reply to comment #6)
> > I see a potential regression in that the whole glass area will be effected by
> > this.
> 
> Each toolbar has their own context menu.  The rest of the toolbars currently
> work with glass.


How do you separate the different toolbar behaviors if they use glass? For instance in Bug 575248, double clicking any glass area unmaximizes the window now, even if it's the tab bar. Will the same method for this bug be used for it?

Comment 11

[[not reading bugmail]]

(In reply to comment #9)
> > (In reply to comment #6)
> > > I see a potential regression in that the whole glass area will be effected by
> > > this.
> > 
> > Each toolbar has their own context menu.  The rest of the toolbars currently
> > work with glass.
> 
> 
> How do you separate the different toolbar behaviors if they use glass? 

I'm guessing with inclusion/exclusion of each toolbar similar to what the patch in bug 555081 did, in this case, maybe un hooking it.

Comment 12

[imradyurrad]

Should be bumped to blocking beta4

Comment 13

[Jim Mathies [:jimm]]

(In reply to comment #12)
> Should be bumped to blocking beta4

Not If it stays assigned to me, I'm on PTO till the 18th.

Comment 14

[Jim Mathies [:jimm]]

Attachment: sysmenu patch v.1

Comment 15

[Jim Mathies [:jimm]]

Comment on attachment 470838 [details] [diff] [review]
sysmenu patch v.1

Easy one for review.

Comment 16

[Jim Mathies [:jimm]]

confirmed, also works on aero basic.

Comment 18

[Jim Mathies [:jimm]]

Comment on attachment 470838 [details] [diff] [review]
sysmenu patch v.1

switching out reviewers, rob's busy with school.

Comment 19

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 470838 [details] [diff] [review]
sysmenu patch v.1

looks good to me!

Comment 20

[Tomas]

Is it worth to be included in b7?

Comment 21

[Please Ignore This Troll (Account Disabled)]

if it works - why not? the patch got a review+, it shouldn't brake anything, as it doesn't affect anything than title bar context menu.

Comment 22

[Jim Mathies [:jimm]]

http://hg.mozilla.org/mozilla-central/rev/927ede69305b

Comment 23

[[e-mail]]

Comment on attachment 470838 [details] [diff] [review]
sysmenu patch v.1

>     case WM_RBUTTONUP:
              ^
>+                                      (TPM_LEFTBUTTON|TPM_RETURNCMD|TPM_TOPALIGN|
                                             ^^^^
This should match the button used to invoke the popup menu, so that you can use the same button to select the desired action. (Does this code actually belong under WM_CONTEXTMENU?)

Did you consider using TPM_NONOTIFY?

>+                                       (mIsRTL ? TPM_RIGHTALIGN : TPM_LEFTALIGN)),
Do you need to use TPM_LAYOUTRTL? Maybe ehsan would know.

Comment 24

[Jim Mathies [:jimm]]

(In reply to comment #23)
> Comment on attachment 470838 [details] [diff] [review]
> sysmenu patch v.1
> 
> >     case WM_RBUTTONUP:
>               ^
> >+                                      (TPM_LEFTBUTTON|TPM_RETURNCMD|TPM_TOPALIGN|
>                                              ^^^^
> This should match the button used to invoke the popup menu, so that you can use
> the same button to select the desired action. (Does this code actually belong
> under WM_CONTEXTMENU?)

Maybe TPM_LEFTBUTTON|TPM_RIGHTBUTTON? It shouldn't match definitively. You should be able to right click for the menu and then left click to select and item.

Comment 25

[Jim Mathies [:jimm]]

Attachment: include right click select patch

we need to listen for both to mimic normal system menu behavior.

Comment 26

[Neil Lee [:neilio]]

Jim, you probably want someone else to review this.

Comment 27

[[e-mail]]

Comment on attachment 481521 [details] [diff] [review]
include right click select patch

TPM_LEFTBUTTON = 0, clicking the left mouse button always works ;-)

Comment 28

[Nochum Sossonko [:Natch]]

This menu isn't behaving on the latest nightly on Win Vista. maximize/restore/move/size disabled state is off compared with 3.6 (and occasionally completely random).

Comment 29

[Gary [:streetwolf52]]

(In reply to comment #28)
> This menu isn't behaving on the latest nightly on Win Vista.
> maximize/restore/move/size disabled state is off compared with 3.6 (and
> occasionally completely random).

Just confirming on Windows 7.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101007 Firefox/4.0b8pre - Build ID: 20101007080800

Comment 30

[Jim Mathies [:jimm]]

(In reply to comment #28)
> This menu isn't behaving on the latest nightly on Win Vista.
> maximize/restore/move/size disabled state is off compared with 3.6 (and
> occasionally completely random).

(In reply to comment #29)
> (In reply to comment #28)
> > This menu isn't behaving on the latest nightly on Win Vista.
> > maximize/restore/move/size disabled state is off compared with 3.6 (and
> > occasionally completely random).
> 
> Just confirming on Windows 7.
> 
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101007
> Firefox/4.0b8pre - Build ID: 20101007080800

Hmm, working fine here on win7. According to GetSystemMenu docs, the system returns an appropriate menu based on the current state of the window.

Comment 31

[Nochum Sossonko [:Natch]]

STR:

1) right-click to bring up the system menu.
2) change window state (e.g. minimized->maximized)
3) right-click to bring up the system menu

It will be off.

However, if you right-click and bring up another menu in between 2 and 3 it corrects itself and will be right by 3.

Comment 32

[abittner]

tested firefox 4.0 on windows7 (running ffx x86 32bit build on win7x64 though) and the yellow/orange area at the upper left of the firefox windows can still not be doubleclicked (imitating system menu behaviour of normal windows) to close the app/window ("x" or alt+f4 behaviour via the system menu, normal windows apps close or exit themselved when double-clicking the system-menu or program-symbol there).

i guess this is related.

do we have a different bug for that? if not, this bug still isnt solved for me.
thanks.

Comment 33

[Jim Mathies [:jimm]]

(In reply to comment #32)
> tested firefox 4.0 on windows7 (running ffx x86 32bit build on win7x64 though)
> and the yellow/orange area at the upper left of the firefox windows can still
> not be doubleclicked (imitating system menu behaviour of normal windows) to
> close the app/window ("x" or alt+f4 behaviour via the system menu, normal
> windows apps close or exit themselved when double-clicking the system-menu or
> program-symbol there).
> 
> i guess this is related.
> 
> do we have a different bug for that? if not, this bug still isnt solved for me.
> thanks.

bug 610763.