161567 - file menu items don't sink when pushed, like the rest of windows

Status: RESOLVED EXPIRED

(SeaMonkey :: Themes, defect)

Description

[Andrew Saturn]

in Mozilla build 2002080713

normally in Windows, when you click a File menu item, it "sinks" to give a
button or 3d look -- but Mozilla doesn't do this. it draws the "sunken" shape,
but the text does not move (it should move down and to the right).

this may be due to Windows XP's theme system, where the file menu does *not*
sink, except on the "Classic" theme for Windows XP. however, I am not on Windows XP.

this may also be just a Mozilla theme problem, but I'm not experienced enough in
themes to know this.

Reproducible: Always
Steps to Reproduce:
1. open mozilla
2. click an item in the file menu (such as "File")

Actual Results:  The menu for "File" appeared, the "File" object sank, but the
text "File" did not.

Expected Results:  The text for "File" should have sank.

this is very minor, but it's just a little weird... I've seen it on other
programs, such as SmartFTP.

Comment 1

[Andreas Kunz]

That's right, I see this bug, too (2002110308 on Win2k).
Maybe bug 172751 can change that... but I'm not sure at all.

Comment 2

[Andreas Kunz]

Bug 172751 did not fix it.

I'm going to confirm this. 
I just tested several other apps on Win2k: Windows Explorer, NotePad, Netscape
4.8,... all move the text of a depressed menu.
Mozilla imitates the border when hovered/depressed, so it also should imitate
the moving of the text.

Other elements like buttons, toolbarbuttons, bookmarks in the personal toolbar,
even the small icons at the left side of every window bottom that start
MailNews, Composer etc. DO that move, so it would be consistent for the menus to
do the same. 

I'm not sure about the component, so if anybody knows better...

Comment 3

[Andreas Kunz]

Attachment: Possible patch for classic on Windows

This should fix it for Classic theme on Windows.
Don't know:
1) what about modern theme, because it looks different than standard Windows
applications anyway.
2) what about Mac. This bug is about Windows, so this fix might suffice. If
somebody knows what is standard behaviour on MacOS, please tell me.
BTW, this is my first patch, so please don't be too rude if something is
wrong...
I think (from the file path name 'classic/global/win') that this refers to
Windows only (or also Linux??). I also have not tried it yet, but will do so
and write again after more testing with modern theme and classic on Linux and
searching for possible difficulties with other uses of 'menu'.

What this patch does, is imitating behaviour of other buttons that DO look
depressed, which is achieving this depressed look by displacing the padding of
the element and thereby moving the text inside.
You can see the effect (this *does* work, I tried it) for yourself if you
paste:

menubar > menu[_moz-menuactive="true"][open="true"] {
  padding: 3px 4px 1px 8px !important;
}

into userChrome.css in the 'chrome' folder in your profile and completely
restart Mozilla.

Any comments are appreciated.

Comment 4

[Andreas Kunz]

I think it better belongs to 'Themes' because the fix is in a theme file.

Well, this patch compiles and works.
I'm sure for Windows this is the right thing to do (consistent with other
Mozilla buttons and other apps).
Good old Win95 had a different way of highlighting open menu titles: their
background-color (and text color also) changed. But Mozilla does not do this
anyway, so this patch doesn't really change anything.

Mozilla looks/behaves different than all the other apps on Linux (KDE) here, so
the only thing it *can* be consistent with is itself - which this patch does.

On Mac... I don't know, but this patch should not affect Mac at all, so this is
probably ok.

Modern theme has created its own reality where the underlying OS does not matter
and this pressed look is not a bug, but only an enhancement - if at all. So I'll
leave it at Classic for this bug.

This all means: to me this patch looks ready, but component owners or whoever
should have a look at it and decide if it is the right thing to do. 
Thanks!

Comment 5

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 6

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420