216266 - No feedback when hovering over / clicking back / forward buttons' popupmenus / dropdowns

Status: RESOLVED WORKSFORME

(Toolkit :: UI Widgets, defect)

Description

[Håkan Waara]

I'm using Firebird 0.6.1

When hovering over or clicking the little popupmenu by the side of the
back/forward button, I get no feedback that the button is depressed or is
hovered over. This is just a minor nit.

Comment 1

[José Jeria]

Still an issue? Can you be more specific?

Comment 2

[Aaron Kaluszka]

*** Bug 248659 has been marked as a duplicate of this bug. ***

Comment 3

[Aaron Kaluszka]

Yes, see duplicate bug for another description.  This happens on Win98, but not
XP/2003.

Comment 4

[Oomingmak]

The problem exists on Windows 2000 too.

Comment 5

[Ryan Rubley]

Still an issue on 1.0PR - very bad looking with no hover effects on the
back/forward chevrons.

Comment 6

[Ryan Rubley]

Just to add, there is no hover effect under 9x/ME/2000 for the chevron (dropdown
arrows) by back and foward buttons.
Under XP there is a hover effect around the whole button with another hover
effect over the graphic and text if you mouse over that part, BUT if you disable
XP themes and use the Win2000ish looking stuff, you get the same problem of no
hover effects for the chevrons.

Comment 7

[chris hofmann]

I can't reproduce this on my xp sp2 laptop.  I wonder what might be needed to
reproduce?  would also need a patch to consider for 1.0 at this point. 
renominate if a patch becomes available.  thanks

Comment 8

[Ryan Rubley]

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 9

[Ryan Rubley]

Attachment: Big buttons

I'm pretty sure the problem is in classic.jar -
skin\classic\global\toolbarbutton.css
I tried adding:

* {
border-width:10px !important;
border-color: ThreeDHighlight ThreeDShadow ThreeDShadow ThreeDHighlight
!important;
margin: 0px !important;
padding: 10px !important;
}
yet you can see clearly that it affects everything *BUT* the dropdown arrows!
So I have no idea how to fix it if no CSS can touch it.

Comment 10

[Jon Hall]

Was poking at this for a bit, and it's not a fix, but maybe someone else can
come along and finish it up? Just stick it in userContent.css.
Honestly though I suspect the presence of the empty style at the bottom of
toolbar.css means that there is a plan in the works already for the dropmarkers.

.toolbarbutton-menubutton-dropmarker {
  border-width: 1px 1px 1px 1px !important;	
}

toolbarbutton[type="menu-button"][open="true"] >
.toolbarbutton-menubutton-dropmarker,
toolbarbutton[type="menu-button"][buttondown="true"] >
.toolbarbutton-menubutton-dropmarker {
	border-style: inset !important;
	border-width: 1px 1px 1px 1px !important;	
}


toolbarbutton[type="menu-button"][disabled="true"]:hover >
.toolbarbutton-menubutton-dropmarker {
	border-style: none !important;
	border-width: 1px 1px 1px 1px !important;	
	border-color: ThreeDHighlight ThreeDShadow ThreeDShadow ThreeDHighlight !important;
	
	display: -moz-box;
}


toolbarbutton[type="menu-button"]:hover > .toolbarbutton-menubutton-dropmarker {
	border-style: outset !important;
	border-width: 1px 1px 1px 1px !important;	
	border-color: ThreeDHighlight ThreeDShadow ThreeDShadow ThreeDHighlight !important;
	
	display: -moz-box;
}

toolbarbutton[type="menu-button"][buttondown="true"]:active >
.toolbarbutton-menubutton-dropmarker {
	border-style: inset !important;
	border-width: 1px 1px 1px 1px !important;	
	border-color: ThreeDHighlight ThreeDShadow ThreeDShadow ThreeDHighlight !important;
	
	display: -moz-box;
}

Comment 11

[Jon Hall]

Attachment: dropmarker hover css

Sorry for spam again, but I was told mozilla suite already did this after I
sent that last comment. So, I just grabbed the necessary css from the suite's
toolbar.css.

Just paste the css in the attachment into your userChrome.css file and you
should have Suite style dropdown buttons in the toolbar. The forward buttons
disabled image looks misaligned, but should be easy fix.

Comment 12

[Simon Paquet [:sipaq]]

*** Bug 226274 has been marked as a duplicate of this bug. ***

Comment 13

[miahz]

(In reply to comment #12)
> *** Bug 226274 has been marked as a duplicate of this bug. ***

Whoa, so i guess the other bug got duped.  It has had a working patch for a
while now, but the hold up is that while it fixes Win Classic, it semi-breaks XP
(Luna) and possibly other natively-skinned themes.  The problem is with the
bordering of the dropmarker, which conflicts with XP's way of doing menubuttons.
 So either XP's native buttons styles need to be fixed (bug 226274 comment #3),
or perhaps there's another way to hack this effect into the css without further
breakage in native themes.

Comment 14

[Jon Hall]

The duping may well have been better off the other way around since the other
bug had comments by Ben Goodger, but as long as it gets fixed...*shrug*
I don't intend to submit a patch (don't know how anyway), but I'll try to see if
I can works something.

I won't have access to my XP machine (this bug probably affects Win2k3, Longhorn
Beta, and Stardock's theming apps, in addition to XP) for a few more days so
unfortunately I can't see the problem. Without an elegant css solution, I was
thinking something along the lines of this...

- Define another css class for native dropmarker's (sans border) in
toolbarbutton.css
- Add some constructor code to the <xul:dropmarker> XBL definition in
toolbarbutton.xml and with a bit of clerverness make sure the correct classes
are being used, while allowing any other classes set by the theme pass through.
I'm unsure of the syntax, but if there isn't a <broadcaster> somewhere that
provides the particular metrics we need from the OS already (there should
be...firefox already reacts on the fly to OS font changes), maybe
boxModel.getLookAndFeelMetric(), or even computedStyle might do the trick. 

I can think of a css hack that might work, but would make the css even more
complex for themers.

I am a bit fuzzy on certain XBL concepts, so if I am talking gibberish I'd be
grateful for any tutelage. 

Comment 15

[Aaron Kaluszka]

The issue with the way Seamonkey draws buttons is bug 127453.  Attachment 94550 [details]
shows how IE draws the buttons.  Even using Luna, the way the the buttons are
drawn in Firefox is incorrect.  In fixing this bug, it would be good to figure
out how IE draws the split buttons and get it right once and for all.

Summary

IE behavior (Luna and classic):
 Hover over Back: Entire button rises, and is split, and button shows active gfx
 Hover over dropdown arrow: Entire button rises, and is split, and button shows
active gfx
 Click on Back: Entire button is pressed, and is split, and button shows active gfx
 Click on dropdown arrow: Back rises while dropdown is pressed, and button shows
active gfx
Firefox behavior (Luna):
 Hover over Back: Entire button rises, and is split, and button shows active gfx
 Hover over dropdown arrow: Entire button rises, and is NOT split, and button
does NOT show active gfx
 Click on Back: Entire button is pressed, and is split, and button shows active gfx
 Click on dropdown arrow: Entire button is pressed, and is NOT split, and button
does NOT show active gfx
Firefox behavior (classic):
 Hover over Back: Only Back rises, and button shows active gfx
 Hover over dropdown arrow: No feedback
 Click on Back: Only Back is pressed, and button shows active gfx
 Click on dropdown arrow: No feedback
Seamonkey classic theme behavior (Luna):
 Hover over Back: Entire button rises, and is split but dropdown button is
themed wrong, and button shows active gfx
 Hover over dropdown arrow: Entire button rises, and is NOT split but dropdown
button is themed wrong so it looks somewhat split, and button does NOT show
active gfx
 Click on Back: Entire button is pressed, and is split but dropdown button is
themed wrong, and button shows active gfx
 Click on dropdown arrow: Entire button is pressed, and is split but dropdown
button is themed wrong, and button does NOT show active gfx
Seamonkey classic theme behavior (classic):
 Hover over Back: Entire button rises, and is split, and button shows active gfx
 Hover over dropdown arrow: Entire button rises, and is split, and button does
NOT show active gfx
 Click on Back: Entire button is pressed, and is split, and button shows active gfx
 Click on dropdown arrow: Back rises while dropdown is pressed, and button does
NOT show active gfx

Also, under Linux, you can see the back button overtop of another button since
each has its own defined borders, probably an artifact of this whole mess.  I
hope I got all that right.

Comment 16

[Jon Hall]

I believe miahz's patch, and the usercontent css attached both fix the hover
behaviors.
The only thing left to figure out is how to stop defining css borders on the
dropmarker when a native widget is used. If someone else doesn't get to it
first, I'll probably have a fix as soon as I get my xp system back up.


Funny you mention figuring out exactly how IE does it, last night I did just
that. I whipped together a winform app with different sized toolbar dropdown
buttons on it so I could see how MS implements them. 
Screenshot: http://img.photobucket.com/albums/v259/red_avni/21fcc930.png
Binaries + SharpDevelop project/source if anyone wants:
http://weblogtoolscollection.com/uploadbin/download.php?pid=71 (no password, I
just felt uploading .net code to bugzilla was a bit too sacreligious even for me). 

Comment 17

[Jon Hall]

After some digging, it looks like this bug has been fixed for GTK in bug 255911
and bryner's comments are quite illuminating. 

I think one could start with @mozilla.org/chrome/chrome-native-theme;1 and
access the new GetWidgetBorder() and determine if theming is active from the
chrome, but that still leaves the issue of the border between the splitbuttons
which I can't see a way to handle from the chrome using just the toolbarbutton
-moz-appearance. 

Comment 18

[Ryan Rubley]

Just tried the latest nightly 20041026 and put that css from
https://bugzilla.mozilla.org/attachment.cgi?id=160319&action=view into my
userChrome.css and it works very nice in win2000. However, it does make things
look worse in WinXP.
This is still a big issue for non-XP users I think.

Comment 19

[Stefan Geisseler]

Attachment: how it should work

Would be nice, if it works like that :-)

Comment 20

[Stefan Geisseler]

If you fix that in the default theme, other themes will follow.
Now, also good themes rarely have such a feature.

Comment 21

[scratch]

the problem with making this look right under luna (or any other xp theme) is
that setting -moz-appearance: toolbarbutton for
.toolbarbutton-menubutton-dropmarker ignores :hover for some odd reason.  if
anyone can figure out why that is and how to fix it, i could probably put
together a patch for this.

Comment 22

[scratch]

Attachment: userChrome.css code that vastly improves the look of menubuttons.

this should really be properly fixed via bug 243078, but just now i put
together some CSS code that vastly improves the situation under both Classic
and Luna on XP.  if people could give some feedback, that might be good.  For
now, just add this to userChrome.css.  If people like it, I'll create a patch.

Comment 23

[Kris Silver]

On 10x XP Home, Pro SP1+2 systems I used Firefox on, this seems to be a problem.
 More precisely, when hovering over the main BACK button itself you can see the
thinner button of back pages dropdown (mini history) but when you hover over it,
the divide disapears, meaning its not clear which button or function is being
hovered over or about to be pressed.

 Also, the tooltip stays the same of GO BACK ONE PAGE, when for that function,
that is false.  It will infact open a dropdown of pages going back many pages,
like a mini history, to then click on.

Comment 24

[Stefan Geisseler]

Attachment: best fix for Win XP classic theme

This works better for me than any other fix here - The buttons don't change
size and the buttons work fine

Comment 25

[James C]

(In reply to comment #24)
> Created an attachment (id=198180) [edit]
> best fix for Win XP classic theme
> 
> This works better for me than any other fix here - The buttons don't change
> size and the buttons work fine

That looks good to me on Win98, except the dropdown arrows shouldn't be
'disabled' when the button is pressed

Comment 26

[Stefan Geisseler]

Attachment: Even shorter / better patch

More unneeded code removed.
Now it should be clearer what to add as a real patch. I'll try to make more
tests also on XP Luna and try to make a real patch out of it after my exam
tomorrow :-)

Comment 27

[James C]

Attachment: added padding rules

This makes the dropdown arrow move 1px to the right when clicked on.

Comment 28

[James C]

Attachment: better padding rules

Using -moz-padding-start and -moz-padding-end instead of padding-left and
padding-right

Comment 30

[Kai Liu]

Although these dropdown buttons are no longer used in Firefox itself, they are still used in Thunderbird, Sunbird, SeaMonkey, and various extensions.  With bug 426660 landed, it is now possible to apply styles that are specific to Classic without interfering with the Luna theme.  So I think it may be worthwhile to revisit this issue...

Comment 31

[Kai Liu]

Attachment: patch

Patch.

Some notes...

* :hover and :hover:active will match the button, the dropmarker, and the dropdown menu

* [buttondown="true"] and [buttonover="true"] will only match if the hover or mousedown is over the button (excludes dropmarker and menu)

* It is thus possible to remove some of the buttondown/buttonover rules if they are already covered by :hover and :hover:active (in case anyone was wondering why I don't use buttonover in this patch)

* A buttondown selector was used instead of :hover:active for setting the depressed state of the button.  This is because of a few minor quirks with how the XUL menu button works (the button will otherwise "press" every time the menu enters and exits an open state, and the depressed-state padding shifts track the buttondown selector, not the :hover:active selector).  Aside from this (personally, I think it looks a bit better this way anyway), the end behavior produced by this patch is identical to that of the native Windows dropmarker menu buttons.

* Removed the !important from "border: none" (on line 158).  !important is not used in the dropmarker style, and since the definitions here in toolbarbutton.css appear later in the order, !important is not needed.  !important is needed, however, for the disabled state, so I added it there.

* Removed the !important from "-moz-appearance: none" (one line 156).  Same reasons as above.

* Added a "-moz-appearance: toolbarbutton" to the classic code.  This is basically a fallback for third-party non-classic themes and has no effect on classic's rendering (or on mainstream Luna/Royale/Zune/Aero rendering, since they will never enter that block in the first place).

* I've tested this patch on both Firefox (using an extension that used such a button) and Thunderbird, on both XP Classic and XP Luna.  None of the mainstream themes (Luna/Royale/Zune/Aero) are affected by this patch.

Comment 32

[Kai Liu]

Nominating blocking to pick up wanted.

* This is a pretty serious and glaring bug for users of Classic.  Just fire up the latest Thunderbird nightly (or any Thunderbird, for that matter) on Classic and observe how visually jarring the behavior of the dropmarker menu buttons are.

* Although Firefox 3 no longer uses these dropmarker menu buttons in the main product, there are many extensions that make use of this widget.  One prominent example would be AdBlockPlus (you can use ABP's toolbar button to test this behavior on Fx3).  And then there's TB3/SB and SM2.

* The primary reason for not fixing this was that it wasn't possible to fix it without breaking Luna.  With bug 426660, this is no longer the case, and I propose that we make use of this opportunity to fix this long-standing bug.

* The fix is, I think, pretty low-risk (just some Windows-specific CSS).

Comment 33

[Damon Sicore (:damons)]

Not going to block 1.9.

Comment 35

[(no longer active)]

Comment on attachment 317461 [details] [diff] [review]
patch

I think the sr request was an accident, right?

Comment 36

[Kai Liu]

(In reply to comment #35)
> (From update of attachment 317461 [details] [diff] [review])
> I think the sr request was an accident, right?
> 

I thought things in toolkit needed sr?  I wasn't sure who to ask, though, so I left it blank.

Comment 37

[(no longer active)]

They don't: <http://www.mozilla.org/projects/toolkit/review.html>

Comment 38

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 317461 [details] [diff] [review]
patch

If you're using only a 1px border, I think you should probably prefer just using border-(left|right|top|bottom) instead of -moz-border-*-colors?

Comment 39

[Dão Gottwald [:dao]]

(In reply to comment #31)
> * Added a "-moz-appearance: toolbarbutton" to the classic code.  This is
> basically a fallback for third-party non-classic themes and has no effect on
> classic's rendering (or on mainstream Luna/Royale/Zune/Aero rendering, since
> they will never enter that block in the first place).

If this isn't right Luna, why is it right for third-party themes?
If it's actually not right for third-party themes, I'm afraid we don't want to solve it like this, especially not now. FWIW, :-moz-system-metric(windows-default-theme) is a hack in itself, and in toolkit code it's an indication for another bad hack.
Note that the toolbarbutton-menubutton rendering is wrong on Luna as well. It needs native widget work.

(In reply to comment #38)
> (From update of attachment 317461 [details] [diff] [review])
> If you're using only a 1px border, I think you should probably prefer just
> using border-(left|right|top|bottom) instead of -moz-border-*-colors?

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

Comment 40

[Kai Liu]

(In reply to comment #39)
> If it's actually not right for third-party themes, I'm afraid we don't want to
> solve it like this, especially not now.
>
Yes, that is one of the downsides to this.  In any case, what we really need (short of moving all the toolbar button rendering into native, which would be far too drastic at this point in time) is a different metric, to distinguish between uxtheme and non-uxtheme.  Not only would that allow us to fix this bug without any negative side effects, but it would also allow us to un-kludge some of the stuff that's been done recently in winstripe.  And it's sufficiently non-invasive, low-risk, and simple that it might even get a green light from the drivers.

I meant to write and test a uxtheme system-metric patch this afternoon, but I never got around to it.  Maybe later tonight, and then the drivers could shoot me tomorrow for proposing something this late.

Comment 41

[Dão Gottwald [:dao]]

(In reply to comment #40)
> In any case, what we really need
> (short of moving all the toolbar button rendering into native, which would be
> far too drastic at this point in time) is a different metric, to distinguish
> between uxtheme and non-uxtheme.

Well, given that we don't need to fix this bug for 1.9 (it's both minor and ancient), I don't think another metric is what we need for this.

> it would also allow us to un-kludge some
> of the stuff that's been done recently in winstripe.

Indeed.

Comment 42

[Dão Gottwald [:dao]]

(In reply to comment #41)
> > it would also allow us to un-kludge some
> > of the stuff that's been done recently in winstripe.
> 
> Indeed.

I was thinking of bug 349859 here, not the location and search bar, since native styling can actually be seen as a good thing there...

Comment 43

[:Gijs (he/him)]

I think both the back/fwd buttons and toolbar-menubutton buttons generally look OK on Windows at this stage, so I don't think it's helpful to keep this open. If there are specific remaining styling issues we should open new bugs for those with more details about how they apply.