Closed Bug 46039 Opened 24 years ago Closed 23 years ago

Back / Forward drop down don't show with click and hold

Categories

(Core :: DOM: Navigation, defect, P3)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: johng, Assigned: hyatt)

Details

Navigate some, go back and forward.  Click and hold back (or forward) button, 
but drop down does not appear.

Build 2000072008 as well as earlier builds.
nsbeta3, regression
Keywords: nsbeta3, regression
Note I am only talking about click and hold - feature works if you click the 
tiny arrow.

cc'ing German to confirm that click and hold *should* work.
Summary: drop down histories for Back and Forward do not show → Back / Forward drop down don't show with click and hold
John, I was under the impression that we are not going to do the Nav 4.x style 
of Click and hold due to visibility reasons. I understand that we are going 
to do only the tiny arrow like in IE.
My understanding was that it was desirable to support both modes, for both better 
discoverability and backwards compatibility. I remember somebody (hyatt) having 
stated that click and hold was difficult to impement for this time frame. I do 
not have any usability data to support that we *need* to keep supporting click 
and hold even with this new design though, but I'd imagine that at least for Mac 
and some other 4.x users it would be beneficial.

I heard from hyatt too that click and hold was tough. This s'd probably go in 
RFE then. This is definitely not regression. This was not working at all at any 
time.
nav triage team:
[NEED INFO]
reassigning to Hyatt
Hyatt, how hard is this?

ccing Lake for usability info
Assignee: radha → hyatt
Whiteboard: [NEED INFO]
Thought we have not expressly tested for the click and hold we should recognize 
that the arrow is tinney. This decreases visual recognition as well as the 
percieved click target area making it more difficult to mannipulate. Having both 
really increases the probability that the user will use it and not become 
frustrated.
Should have made the button rectangular and the arrow larger. Not adding timer. 
resolving as invalid
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Whiteboard: [NEED INFO] → [NEED INFO][nsbeta3-]
Invalid! Is that the right answer? You are saying we are never going to have this and moreover we shouldn't?

Never mind the fact that 4.x worked that way on all platforms and click+hold is a common gesture on the Mac?

reopening for reconsideration. Note, I'm not arguing +,- here, I'm just saying it's not invalid
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Yes, that is exactly what I'm saying, and it is something we have consistently
said for over a year now.  Button widgets are buttons, not some wierd
button/menu monster.  If you want a menu, add a decent-sized arrow. In 4.x, we
also have at least one menu that pops up only on the mouse-UP; would you contend
that we have to reproduce *that* idiocy for backward compatibility? resolving as
invalid, lets not spend any more time on this.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → INVALID
Target Milestone: --- → Future
hrmpf. marking VERIFIED although I'm dismayed.

I outuse the menu over the button 10-to-1 and would've
liked to see it made easier to use(bigger arrow doesn't cut it) but oh well.

I'd like to see this re-opened for beta 3. reasons:
useful for 
a) mac users 
b) peopled used to 4.x
Status: RESOLVED → REOPENED
Keywords: UE2
Resolution: INVALID → ---
c) anyone who has trouble hitting that tiny little arrow target.
No, for these reasons:
0) The time to discuss this was late '98 - early '99, when we made the decision.
(Don't play with dead snakes)
1) The button/menu is an abominable monster, not fit as either a button nor a
menu. (Internal consistency)
2) The current widget design is a defacto standard widget, in use on the vast
majority of desktops. (Do the same as everybody else)
3) There is an easier resolution - don't make the arrow microscopic!
(Conservation of energy)
4) The arrow works quicker, since there is no delay. (Faster is better)
5) Due to time/resource constraints, and reasons 1-4, this isn't even worth
arguing about in the last few weeks before we ship. (End of discussion, get over it)
Note:  I am a Mac user, very used to 4.x, and ready for bifocals. Please, just
make the arrows a reasonable-sized target.  Sacrifice a little visual
stylishness for usability.
you said it peter
filed bug 48303 to see if we can get the arrow a little bigger. (in case we lose this battle :-)

>> 0) The time to discuss this was late '98 - early '99, when we made the 
decision. (Don't play with dead snakes) <<

Hmmm... that's funny.  I remember discussing this quite a while ago and 
getting quite the same response even then: just a curt, unprofessional 
shutting down of discussion.

>> 1) The button/menu is an abominable monster, not fit as either a 
button nor a menu. (Internal consistency) <<

That's your problem, not the users.

>> 2) The current widget design is a defacto standard widget, in use on 
the vast majority of desktops. (Do the same as everybody else) <<

No, it's not a defacto standard widget.  Even so, those buttons that are 
similar have the very same problem.  (Do the same as everybody else 
and you're no better.)

>> 3) There is an easier resolution - don't make the arrow microscopic!
(Conservation of energy) <<

That only solves part of the problem since no matter how large the arrow 
is, it's still hard to hit and the only way to access the menu.  A *better* easy 
solution is to add a right click option to the main button as well (which I 
proposed long ago and was shut down).

>> 4) The arrow works quicker, since there is no delay. (Faster is better) 
<<

WRONG.  Faster is NOT always better.  And in this case, it is NOT faster 
since it is so damn hard to hit.  Larger target = easier to use.

>> 5) Due to time/resource constraints, and reasons 1-4, this isn't even 
worth arguing about in the last few weeks before we ship. (End of 
discussion, get over it) <<

Oh, grow up, would you?  These issues are being raised now because 
the UI group has been told, with EVERY SINGLE MILESTONE, that UI 
bugs will get fixed in the next milestone.  We HAVE been discussing these 
things; some people have chosen not to listen.

>> Note:  I am a Mac user, very used to 4.x, and ready for bifocals. Please, 
just make the arrows a reasonable-sized target.  Sacrifice a little visual
stylishness for usability. <<

Visuals mean nothing if the behaviors aren't right.  "Stylishness" is far 
from our most important concern here.  We don't make these requests 
just to save OURSELVES the trouble of making changes you know.

I'm getting very annoyed by this, but we don't really know each other, so I'll
try to be civil. Bugzilla is not a fit medium for such emotional content.  If
you or anyone else wants to insult me, or argue about this, or even discuss it
politely, the place to do that is in person, not in this bug.  Please stop by,
or call a meeting or something.  However, given the product we're supposed to be
finishing in 5 weeks, I'm amazed that this is one of the issues you want to
spend time on.  We must be a lot closer to shipping than I think.
FWIW, I agree with Peter here. (And I'm a heavy Mac 4.x user.)

This has been discussed several times. 4.x's buttons were a bad design because of 
temporal inconsistency (hold them down for 0.999 seconds and they do something, 
hold them down for 1.000 seconds and they don't), internal inconsistency (the 
tiny triangles didn't make it obvious enough that some buttons could act as 
menus, some were *only* menus, and some were just buttons), external 
inconsistency (no other software I know of uses the same design), and diminution 
of cancelling ability (drag off the button to cancel it too slowly, and you might 
end up choosing a menu item by mistake).

If you're going to do anything to make the menu part of menubuttons easier to get 
at, I suggest this: allow the user to drag from the button to the menu, or vice 
versa, and have the part of the widget she drags to act as if it has just been 
moused down on. That is, I can mousedown on the Back button, drag to the Back 
menu, and the Back menu opens. Or I can mousedown on the Back menu, drag to the 
Back button, and the Back button enters mousedown state. This would solve the 
problem where I mousedown on the Back button, and then realize that I actually 
wanted to go back more than one page.

If you don't like the menu opening after a short delay, you could open the menu
immediately, but still click (closing the menu) if the mouse is released over
the button. At least you'd avoid confusing Mac owners :-)
Clicking outside of an open menu shouldn't have any side-effect other than
closing the menu.  BTW, this isn't about what we, as individuals, like; it is
about what we should do for users, and are able to do in this release.
Sorry, I was commenting on the fact that 4.x used a timer so if you weren't 
careful you could click on the menu that was just about to appear.
I just want to make a point that at least one person I know has decided that he 
hates Netscape 6 because of this one issue and deleted it from his system.

If you need to add a new type of wiget do so, or just start a timer onMouseDown 
and cancel onMouseUp. But this does need to be fixed.
Keywords: nsbeta3, regression
Whiteboard: [NEED INFO][nsbeta3-]
nav triage team: not a beta stopper
Keywords: nsbeta1-
NOt fixing.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WONTFIX
Keywords: UE2
mass-verifying WontFix bugs which haven't changed since 2001-12-31.

use the search string "BoletusEdulis" if you want to filter out this msg.
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.