From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (Win98; U) BuildID: 2000051609 In today's build, the back and forward menubuttons' appearance has changed. However, the new menubuttons are a *very* small target. As an interim solution, I've come up with a replacement, if you want to use it. First, grab these two images: http://www.mozillazine.org/problems/tb-menubutton-dm.gif http://www.mozillazine.org/problems/tb-menubutton-dm-disabled.gif and replace the images of the same name in /chrome/skins/modern/communicator/skin/ Then, in that same directory, open up menubutton.css, scroll down to ".menubutton-dual-dropmarker-box", change the margin-left to 27px, and save the file. Restart Mozilla. This button provides a bigger target. In the long run, it might not be the best solution, but I think it helps out with the small-target problem that people have mentioned today. Reproducible: Always Steps to Reproduce: Open Mozilla :-)

I recommend a behavioral change to increase the target size rather than just a visual one. My recommendation for *all* combination button/menus is that they have multiple access methods. * A single click on the button activates it. * A single click on the admittedly small menu triangle displays the menu. (This makes it discoverable, if hard to target.) * Click and hold on any part of the button displays the menu. * Right click/ctrl+click on any part of the button displays the menu. This gives us a visible indication that there is a menu (whether it's the new icons or the old ones), a small, but discoverable method of accessing the menus directly, and other faster, more usable, though less discoverable methods of accessing the menus. Reassigning to XP Toolkit/Widgets.

This is more of a skins issue, but I'll use it as an opportunity to toss in my $.02. I think the menu part of the buttons are not just a tiny target, they are nearly invisible, and are an ugly addition to the round buttons (which I dilike anyway). I would greatly prefer following the defacto Windows standard widget a bit more closely here. The current situation is even worse than a quick look appears - while the button is round, the target areas are rectangular, and extend well outside of the visible target. In fact, the menu portion extends well into the round button portion, which is just wrong. If these things are a rectangular target, let's show them that way. As to Brendan's suggestions: * Single click should certainly activate: if it looks & quacks like a button... * Single click on a much larger menu target, with a more visible triangle, ~ * Click and hold to popup menu means it no longer acts like a button, and requires timing code that the engineers don't want to write. Not gonna do it. * Modified click is completely undiscoverable, so why bother? In any case, this bug is ben's, reassigning.

To summarize what I said in n.p.m.ui a few days ago about menubuttons ... * The button part should act just like a button, with no timers. * The menu part should act just like a menu, with no timers. * Dragging from the button part to the menu part should open the menu, just as if it was the menu part which had been clicked initially. * Dragging from the menu part to the button part should close the menu and depress the button, just as if it was the button part which had been clicked initially. This would make a larger target for the menu part of the menubutton, without resorting to timers or other undiscoverable techniques. It would also cater for those situations where you realize in mid-click that you actually want to go back more than a single step -- just drag from the button part to the menu part, and the menu opens.

* The button part should act just like a button, with no timers. I would like, however, the possibility of having right-click access to the history menu. But this might be possible through XBL. * The menu part should act just like a menu, with no timers. right - however, both the "base" button and the "dropdown" button should be able to inform the other of hover events, etc. IE's dropdown behavior is the most common implementation now - it would be handy to be able to emulate the behavior exactly. [to Ben: Please???] My post in .ui and .xpfe (news://news.mozilla.org/3925B92B.F72AA5AD%40bellatlantic.net) details the behavior. * Dragging from the button part to the menu part should open the menu, just as if it was the menu part which had been clicked initially. * Dragging from the menu part to the button part should close the menu and depress the button, just as if it was the button part which had been clicked initially. This is a good idea, and extends the behavior of IE's menubuttons - the only issue would arise if the buttons didn't have target areas that were contiguous - which is quite possible if people are skinning the app.

Move to M21 target milestone.

Okay, clearly some of us have agendas that *don't* include users. The solutions I gave you address *all* the issues here and the arguments against have little or nothing to do with the original problem. Allowing a right-click on the button not only gives you a HUGE target, it already takes advantage of an expected behavior: right click, get a menu. As for the comment that "Modified click is completely undiscoverable, so why bother?" there are ENDLESS features in this product and many others that are technically undiscoverable -- THAT DOESN'T MEAN THEY ARE USELESS. In this case, if the right mouse button is undiscoverable, then please go out and tell the world to get rid of their multi-button mice. Even many Mac users have multi-button mice now and those that don't are quickly learning the control-key equivalent. Either way, this is not a hidden feature. You can access the menu via other methods. This is simply a shortcut for people who take the time to find out about it. Next, the complete rejection of the mere suggestion of a timer is mind-boggling. You *have* some kind of a timer already: tooltips do not appear instantly so something is delaying them. If you can delay a hover, why can't you delay a click? Also, there is no reason not to have a timer on a button or a menu. It does not interfere with normal operating behavior in ANY way. You can use the button and the menu exactly the same way you always did. If you hold down the mouse, however, you get *additional* behavior. Thus, there is no 'just act like a button, no timers.' The timer does not affect the button behaving like a button. Finally, the drag back and forth between menu and button in no way precludes these other behaviors. Drag is a separate action that can perform a different function. However, the behaviors will need to be made coherent so that nothing erratic happens. For example, if a right click is used, that should probably override any dragging since that would be an exclusive menu access command. And as an aside, this has nothing to do with skins. Skins are surface level visuals. This is a behavioral issue that would affect all button/menus, no matter what the skin looked like.

Ah. Now I see why Brendan left. :-) At the very least, could we get larger triangle graphics to make the buttons wider? It would take about ten minutes to do for Classic (a bit longer on Modern), and would improve usability no end -- especially since the Back button is the most commonly used button in the browser.

this is not a problem on classic, only modern. certainly not an XPToolkit issue, anyways.

This is *so* a problem on Classic. (Perhaps just Classic Mac?)

On Windows, Classic skin, the history dropdown buttons are quite large now. There is still a bug in their behavior that needs to be addressed, and I hope to get around to filing it today.

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

[Transferring status/keywords from bug 48303]

-> Paul Hangas, as this is a modern2 only issue.

PDT marking [rtm-]. Not on Paul's list of top issues.

Restoring classic keyword which Ben removed, as this is still a problem on Classic, build 2000101620, Mac OS 9.0 -- the dropdowns still look like <http://bugzilla.mozilla.org/showattachment.cgi?attach_id=15258>. So there is *no* skin shipped with Mozilla which has menubutton dropdowns large enough for comfortable use, and this is starting to get annoying. Other ideas mentioned in this bug now have their own bugs: * bug 53664, `Button and menu parts of menubuttons should share mousedown target areas' * bug 55764, `Right-click on button part of menubutton should open menu'. But both of those are additional enhancements, not solutions to the basic problem described in this bug of the dedicated menu target area being too small.

On Windows98 the menubutton in Classic is fine - larger than IE 5.5's menubutton. I agree that on Mac it looks absurdly small. Seems like a problem both with triangle size and padding around the triangle. This should be a very simple fix and would increase the usability of the Mac classic skin. Maybe not a top issue, but simple enough to fix that I don't think a fix should be turned down for RTM if submitted.

Sending to Hewitt.

The Modern menubutton arrows were enlarged long before RTM. I'm sure there will still be folks who think it is too small, but given the current design they aren't going to be enlarged again. Mac Classic may still be too small, so over to andreww.

Looking at this today - fix should be ready very soon.

ok found out finally where this is defined and looks like all I need to do is add some padding and it works fine: (communicator/menubutton.css) .menubutton-dual.toolbar > .menubutton-dual-dropmarker-box { border : 1px solid transparent; padding : 1px 2px 1px 2px; } /** new code **/ .menubutton-dual.toolbar[open="true"] > .menubutton-dual-dropmarker-box { /* border-left : 1px solid threedshadow; border-top : 1px solid threedshadow; border-right : 1px solid threedhighlight; border-bottom : 1px solid threedhighlight; */ border : 1px inset #FFFFFF; padding : 2px 2px 0px 2px; } /** new code **/

I suggest making the triangle 7 pixels wide (instead of 5), as well as adding 1 pixel padding on each side (instead of none). Now that the triangle graphic is not sharing space with toolbar icons as it was in 4.x, there is no reason to keep it as tiny as it was then; and making it so small makes it unnecessarily difficult to see what that part of the button is for.

Themes Triage Team nsbeta1+

preparing a diff... as the posted patch is not in diff format

r=hewitt

a=hangas

setting platform, milestone, os...

Fixed.

Marking verified on Mac and windows (2001-01-25-08-Mtrunk).

Not an ActiveX Wrapper bug, back to -->Themes.