655265 - [Classic] In Windows Classic Theme there is no feedback when hovering over or clicking menu-toolbarbuttons and dropmarkers.

Status: RESOLVED FIXED

(SeaMonkey :: Themes, defect)

Description

[Philip Chee]

From Bug 216266:

> I have a brand new laptop I just got a few days ago, with XP SP2 and a fresh
> install of Firefox 1.0PR. The only thing that is needed to show this issue is to
> go to Control Panel, Display Properties, pick the Apperance tab, under Windows
> and buttons you have two choices: Windows XP style and Windows Classic style. 
> Pick Windows Classic style, then switch over to Firefox, go to any page, click
> on any link, and move your mouse over the back button.  You can be using small
> or large icons, and icons or icons and text, it doesn't matter.  The outline
> that appears when you hover over the back button does not include the little
> arrow pointing down that provides the list of choices to go back to.  Hovering
> over the arrow itself does not outline anything at all.  It seems even worse
> with text-only buttons since there is not even an arrow there at all, and the
> only way to get a list of choices to go back to is to right-click the back button.
> All of the functionallity still works fine with the back button and the arrow
> button that is part of it, but it is very bad looking to not show a hover effect
> around the little arrow piece like all of the other buttons do.

Comment 1

[Philip Chee]

Attachment: Patch v1.0 Proposed fix.

The Toolkit/widget bug (Bug 216266) has been stalled for ages. This is a SeaMonkey specific fix while waiting for a more comprehensive fix in Core.

Note: -moz-border-*-colors is needed to override dropmarker.css.

Comment 2

[Philip Chee]

Yeah yeah I'll fix the brackets in a subsequent patch.

Comment 3

[[e-mail]]

Comment on attachment 530642 [details] [diff] [review]
Patch v1.0 Proposed fix.

>+  toolbarbutton[type="menu-button"]:hover > .toolbarbutton-menubutton-button:not([disabled="true"]),
I don't really like this...

>+  toolbarbutton[type="menu-button"][open="true"] > .toolbarbutton-menubutton-button:not([disabled="true"])
Not sure what the point of this is, since it gets overridden immediately.

>+  toolbarbutton[type="menu-button"][open="true"] > .toolbarbutton-menubutton-dropmarker:not([disabled="true"])
Disabled menubuttons are unlikely to be open.

>+    -moz-padding-start: 3px !important;
>+    -moz-padding-end: 1px !important;
What's this for?

Comment 4

[Philip Chee]

Attachment: Patch v1.1 Fix nits.

>>+  toolbarbutton[type="menu-button"]:hover > .toolbarbutton-menubutton-button:not([disabled="true"]),
> I don't really like this...
Removed. But Attachment 94550 [details] indicates that this was how it looked way back then in both MSIE and the old Mozilla Suite circa 2002.

>>+  toolbarbutton[type="menu-button"][open="true"] > .toolbarbutton-menubutton-button:not([disabled="true"])
> Not sure what the point of this is, since it gets overridden immediately.
Removed.

>>+  toolbarbutton[type="menu-button"][open="true"] > .toolbarbutton-menubutton-dropmarker:not([disabled="true"])
> Disabled menubuttons are unlikely to be open.
Specificity needed to override the previous style rule.

>>+    -moz-padding-start: 3px !important;
>>+    -moz-padding-end: 1px !important;
> What's this for?

From Bug 216266 Comment 27:

> Created attachment 198928 [details]
> added padding rules
> 
> This makes the dropdown arrow move 1px to the right when clicked on.

Comment 5

[[e-mail]]

Comment on attachment 530846 [details] [diff] [review]
Patch v1.1 Fix nits.

>+    -moz-padding-start: 3px !important;
>+    -moz-padding-end: 1px !important;
Does it need to be important, and also I'd like it to move down 1px too.

Comment 6

[Philip Chee]

Pushed:
http://hg.mozilla.org/comm-central/rev/300882418350
http://hg.mozilla.org/releases/comm-2.0/rev/784b1198d9bb

Comment 7

[Philip Chee]

Attachment: Patch v1.1a As checked in.

>>+    -moz-padding-start: 3px !important;
>>+    -moz-padding-end: 1px !important;
> Does it need to be important,
No. Too much cut and paste from the original patches.

> and also I'd like it to move down 1px too.
Fixed.

Comment 8

[rsx11m]

Attachment: Screenshot of new behavior

Phil, Neil: Interesting observation in today's nightly, I don't know if it was intended this way or sneaked in. Come with the mouse from the right and move it into the hover range or a button with a drop-down menu:

 - top: no hover state, mouse is outside of the button region
 - center: mouse is now in the hover range of the drop-down menu
 - bottom: mouse moved left into the hover range of the button

The behavior shown in the center is a bit unexpected, given that the button shows "hover" feedback (changed icon) without having a hover-button border.

Fine with me, just wondering if you want to look into this for a follow-up if indeed it wasn't planned to behave like that.

Comment 9

[Philip Chee]

> The behavior shown in the center is a bit unexpected

See Comment 4 starting with:

>> I don't really like this...
> Removed. But Attachment 94550 [details] indicates that this was how it looked > way back then in both MSIE and the old Mozilla Suite circa 2002.

So yeah Neil wanted it this way, mutter mutter.

Comment 10

[rsx11m]

Ok, thanks. I didn't connect the dots when reading over the comments...

On the other hand, it provides a clearer distinction this way whether you are hovering over the button or over the menu, thus it's not without benefits.

Comment 11

[rsx11m]

> (comment #10) it provides a clearer distinction this way whether you
> are hovering over the button or over the menu

(with "it" meaning "as you now implemented in this bug", that was ambiguous.)