102330 - Back/Forward menu gets stuck on click-and-hold

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Matthew T (active 1999-2002)]

Build: 2001092008, Mac OS 9.1

To reproduce:
1.  Visit a few pages in a Navigator window.
2.  Hold down the mouse on the Back button.

What happens:
*   The Back menu opens.

What should happen:
*   The Back menu should not open, unless the mouse button was held down on the
    menu part of the button.

This causes two problems. If the mouse button is held down on the button part of
the menubutton, it makes it appear as if releasing the button will do nothing
(since no menu item is selected), when it actually goes back one page. And if
the mouse button is held down on the menu part of the menubutton, the window
stops responding to the keyboard completely.

Comment 1

[André Dahlqvist]

Is this perhaps a Mac-specific bug? I can not reproduce this with 2001-09-28-21
on Linux, using the Modern theme.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This _is_ mac-only.  The "back" dropdown menu is actually set as the context menu 
for the back button.  As a result, click-hold brings it up.

This is identical to 4.x behavior on Mac, by the way (not that that's a defence).

Ccing pinkerton who I seem to recall implemented this.

Comment 3

[Alex Bishop]

Vaguely (ir)relevant: In 4.x for Windows, the back/forward context menu could 
be obtained either by right-clicking or holding down the left mouse button.

Comment 4

[riscky]

also a problem under os x (just making that note sorry for the "spam")

Comment 5

[Mike Pinkerton (not reading bugmail)]

this is a dupe of a bug blake already has that the dropdown is set up as the
context menu. buttons don't have context menus. that's terrible UI. fix that and
this bug goes away.

Comment 6

[Blake Ross]

All of the toolbar buttons had context menus in classic and they all will when 
we have toolbar customization in mozilla. We should get used to it.

Well, they did and will on Windows anyways.  We can disable this behavior on Mac 
if desired (apparently it is).  Although mpt seems to be complaining only about 
the fact that the menu appears even when holding down the drop arrow, which is 
obviously incorrect and easily fixed.

Comment 7

[Matthew T (active 1999-2002)]

No, I'm complaining about the behavior in general where holding down the button
for 0.999 seconds will do one thing and holding down the button for 1.000
seconds will do something else. If you think Mozilla should have that behavior,
go reopen bug 65726. While that bug remains invalid, however, click-and-hold
should not open the Back or Forward menus.

Comment 8

[Matthew T (active 1999-2002)]

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

Comment 9

[Michael Finney]

This seems to be a duplicate of, or at least closely related to, bug 115223. The
bad thing that happens (drop-down menu persists in background, stealing keyboard
focus) is the same for both. For most people, this would be perceived as a
crash, as the browser seems to quit (i.e., keyboard doesn't work). This is
serious, and  exactly the sort of bug that keeps me from recommending Moz to my
dad, and other bug-intolerant people.

Comment 10

[Jesse Ruderman]

> If the mouse button is held down on the button part of
> the menubutton, it makes it appear as if releasing the button will do nothing
> (since no menu item is selected), when it actually goes back one page.

Could we move the Back menu so that the first menu item is under the cursor?  I
think that would fix the problem.

Comment 11

[Matthew T (active 1999-2002)]

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

Comment 12

[Matthew T (active 1999-2002)]

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

Comment 13

[Matthew T (active 1999-2002)]

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

Comment 14

[Matthew T (active 1999-2002)]

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

Comment 15

[Matthew T (active 1999-2002)]

This is causing Mozilla to appear to lock up completely, when click-and-hold
opens a second copy of the menu and the first copy gets hidden behind the
browser window. --> hang keyword.

Comment 16

[Daniel Wang]

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

Comment 17

[Martyr]

Yes. The most annoying thing about this bug is not that the history menu opens.
It's that it usually opens *BEHIND* the window and that the keyboard stops
responding to input until you find this menu and close it. (Hitting the Escape
key dismisses it.) This is a serious usability issue -- still present in Moz
1.2beta, Mac OS 9.x. 

Comment 18

[Frankie]

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

Comment 19

[Frankie]

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

Comment 20

[Frankie]

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

Comment 21

[Frankie]

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

Comment 22

[Jo Hermans]

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

Comment 23

[Jo Hermans]

Changing OS-field to OS X, because OS 9 isn't supported anymore, but the bug
still exists (see bug 208698). I'm using build 2003060503 on Mac OS X 10.2.6.

The bug is now a bit different (see bug 208698), and doesn't cause a hang
anymore (comment 15 and comment 17), because the keyboard is still working.
What's happening is that you click-and hold the little button to get the
pulldown-menu. But after a second, you'll notice that the pulldown will flash.
Now, when you choose an url in that window, the window will seem to get stuck,
and won't go away. You can make it go away by pressing the little button again.

I think that by clicking-and-holding, you got the pulldown first, and the
contextual menu secondly. This causes the flash, because a second (but
identical) window is painted on top of the pulldown. When you make a selection
(highlighting the url), the contextual menu will go away, but you're still stuck
with the original pulldown menu (without the highlight).

I think the solution would be to prevent the contectual menu to show while the
pulldown is visible. Or close the pulldown menu when the contextual menu comes
up (but that might trigger a few "double paint" bugs, because it causes a
visible flash).

Comment 24

[Blake Ross]

Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). 
If you want this fixed for Firefox, change the Product and Component accordingly
and reassign back to me.

Comment 25

[Matthew T (active 1999-2002)]

Still happening (as described in comment 23) in Firefox 0.8.

Comment 26

[Asa Dotzler [:asa]]

(This bug made its way to Firefox but the problem exists in both FF and
Seamonkey -- and presumably in Thunderbird menubuttons as well). 

Comment 27

[riscky]

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

Comment 28

[Joel Craig]

Not sure if this is the same bug or not, but I'm noticing on the July 15 nightly
that when I bring up a contextual menu via right-click-and-hold, or
left-click-and-hold, and drag down to the desired action (i.e. Close Tab, Back,
etc.), that the menu hangs, and requires a second click to initiate the desired
action.

Comment 29

[April King [:April]]

Nope, this is a bit different than what I see (and still see).  If you
click (and hold) on the little down arrow in the URL bar (ie, about 3/4
centimeter left of the magnifying glass), that menu will pop up and will cause
your URL bar to jump down at least a couple entries.  It's difficult to explain,
but just click on the down arrow and hold for just a second...

Comment 30

[Martyr]

The only thing that remains a problem with this is that the pop-up menu isn't
transient. I click on the back button for 3/4ths of a second and the pop-up menu
comes up and then stays up. I have to click on another button or hit Escape to
cause it to leave. On the other hand, it doesn't pop-up behind the application,
hang it, or do other weird UI transmorgifications anymore. 

Comment 31

[Uri Bernstein]

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

Comment 32

[Ignacy Niemczycki]

It is still a problem in 1.0. However, the behavior is a bit different from what
is written in the initial report. If you click and hold the big forward/back
arrow itself a menu is displayed and then without letting go the button you have
to choose the page and let go the button. Letting go the button without choosing
anything from the menu causes Firefox to go back just one step. Therefore, FF
handles well this type of situation. However, if you click the little menu arrow
near the big back/forward arrows FF will display a menu (still correct). The
problem is that when you choose a page and click in the displayed menu, FF will
take you to this page, but the menu will not disappear. To sum up the bug in 1.0
is the menu not disappearing after a page has been selected. I would suggest
changing the title of this bug.

Comment 33

[April King [:April]]

Attachment: Screenshot of the error for bug #225727.

Screenshot of my original error in action.

Comment 34

[April King [:April]]

Clearly, my original bug (225727) that got merged incorrectly into this bug is still outstanding.

There are two issues, as far as I can see:

1) Holding down the back or forward buttons results in a menu that won't go away.
2) Holding down the arrow for the history results in both a detached history list, and a menu that won't 
go away.

I have attached a screenshot of the error so that it can perhaps stop being bounced about.  It's still in 
version 1.0, hopefully it can be fixed by the big 1.1 Mac version.

Comment 35

[Asa Dotzler [:asa]]

moving blocking1.0mac bugs to Firefox1.1 Target Milestone.

Comment 36

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

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

Comment 37

[Peter da Silva]

The first problem I see here is that click-and-hold has WAY too short a timeout,
and it's applied in too many cases. Not all Mac OS X objects with menus even
implement click-and-hold as an activation mechanism... icons on the desktop, for
example, require control/right click.

I think Firefox really needs to limit or even eliminate click-and-hold on OS X.
It's not implementing it in a way compatible with native widgets, and a lot of
Mac related bugs would go away if you didn't have menus coming up at the drop of
a mouse.

Comment 38

[Mike Connor [:mconnor]]

Josh, do we need to fix this, or is the current impl ok for DP?

Comment 39

[Josh Aas]

Lets fix it. Its not OK.

Comment 40

[Jo Hermans]

(In reply to comment #37)
> I think Firefox really needs to limit or even eliminate click-and-hold on OS X.
> It's not implementing it in a way compatible with native widgets, and a lot of
> Mac related bugs would go away if you didn't have menus coming up at the drop of
> a mouse.

That's bug 107433.

Comment 41

[Josh Aas]

Attachment: fix v1.0

This patch fixes the problem by simply disabling click-hold. Bug 107433 is for
adding a pref to enable/disable click-hold. I don't think that is necessary at
all, I'd rather see it just disabled. Its buggy, and we don't need to add to
the prefs bloat situation. However, we can leave the code in for developer
reference in the future.

So, this fixes this bug, and I recommend closing 107433 bug as WONTFIX.

This should definitely be off for Deer Park.

Comment 42

[Asaf Romano (gone)]

Comment on attachment 189291 [details] [diff] [review]
fix v1.0

I'm going to work on the pref patch later today, and pref it off (in another
bug) for toolkit apps.

Comment 43

[Mike Pinkerton (not reading bugmail)]

i just want to warn you of the impending backlash if you do this. not that i
disagree, just prepare yourself well.

Comment 44

[Asaf Romano (gone)]

(In reply to comment #41)
 
> So, this fixes this bug, and I recommend closing 107433 bug as WONTFIX.

Well, we have at least one app in the tree which wants it to be turned on,
seamonkey.

Comment 45

[Simon Fraser [no longer active]]

I strongly recommend not disabling click-hold menus. For many less experienced
users, this is the ONLY way they know to get context menus. They have one button
mice, and they don't know to press the control key. You will get streams of
regression bugs that "context menus no longer work" if you do this. We still get
them for Camino.

Comment 46

[Martyr]

This should be fixed. Click-hold is used all throughout OS X and I see no reason
why Firefox shouldn't be a good OS X citizen and use this functionality. Having
it makes the program *much* easier to use and much more intuitive. I use
one-button and multi-button devices and prefer the one button / click-and-hold.
I also agree that you will see oodles of "context menu is broken" type bugs if
you this becomes a WONTFIX. 

Comment 47

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #46)
> This should be fixed. Click-hold is used all throughout OS X and I see no reason

Uh, pardon? From the Apple Human Interface Guidelines for Aqua:

"Pressing and Holding

Pressing means holding down the mouse button while the mouse remains stationary.
Pressing by itself should have no more effect than clicking does, except in
well-defined areas such as scroll arrows, where it has the same effect as
repeated clicking, or in a Dock tile, where it displays a menu. For example,
pressing a Finder icon should select the icon but not open it."

While I'm admittedly new to *using* a Mac as my primary machine, I quickly
checked all of the apps that shipped with OS X 10.4 (ie: Finder & iLife) and was
only able to find two examples of a UI element which used click-hold to invoke a
context menu: the first is a dock tile (which is the exception stated in the
HIG) and the second is Safari (see note below). Can you give some examples of
other apps that behave this way? Is this a change in the OS X behaviour as of Tiger?

(note: Safari uses click-hold to get the history drop-down on its back/forward
buttons, but that seems to be different from the behaviour of Finder, and just a
workaround (that violates Apple's own HIG) to make up for the fact that they
don't have compound drop-down buttons.)

I tend to agree with Josh's recommendation in comment 41, and with reporter: the
drop-down for back/forward should only appear when the drop-down part of the
button is clicked, and everywhere else we should be following Apple HIG on how
to respond to click-hold events.

Comment 48

[Josh Aas]

I wrote this as Mike Beltzner wrote his, so there is some dupe info:

I thought a lot about this today, and in the end I'm sticking with my opinion
that click-hold should be gotten rid of.

The only app I can find on Mac OS X is the dock, and that isn't really an app
the way most users think of apps. None of Apple's iApps or Mail, for example,
use click-hold. So I don't think dropping click-hold is going to make us less
mac-like - if anything, the opposite.

Simon's argument about having click-hold be the only way people know how to get
context menus with a one button mouse is a good one, but I think it is flawed.
Feel free to correct me, but if click-hold is not standard in Mac OS X apps,
then how would people who are actually that novice even find out about it? Seems
to me its more likely that they'll figure out the standard way to get context
menus than they'll experiment with holding the mouse down in Firefox in
particular. What do these people do in iTunes? If they didn't know and actually
tried this in Safari or iTunes (unlikely) and it didn't work there, are they
really likely to try again in Firefox? So I don't think many people are in that
situation.

We will get a few angry people, regression reports, etc., but this seems like
the right thing to do for technical and maybe even conformance reasons. We
cannot keep everyone happy.

We have to make this call, and I think me (a Mac Mozilla developer), Beltzner (a
Mozilla UI person), and mconnor (a Firefox peer), are a qualified group. Of
course, drivers can always override. If anyone disgrees, please say so here.
Beltzner and mconnor: if you agree, lets get reviews and request approval for my
patch.

(Seamonkey can ifdef it on if they like, I never suggested removing the
implementation code)

Comment 49

[Simon Fraser [no longer active]]

(In reply to comment #48)

> Feel free to correct me, but if click-hold is not standard in Mac OS X apps,
> then how would people who are actually that novice even find out about it? 

Both Netscape 4 and IE on Mac have click-hold behavior. For those who've used
the web since the early days on Mac, this is what they've grown up with. Still,
it's your call.

Comment 50

[Gary Elshaw]

Apologies for rehashing an old argument, but I disagree with Simon's and
Martyr's earlier comments:
https://bugzilla.mozilla.org/show_bug.cgi?id=102330#c45 and
https://bugzilla.mozilla.org/show_bug.cgi?id=102330#c46 respectively, in that
the behaviour isn't contextual at all. Contextual info is only there in
single-button devices with the addition of a modifying key. These menus don't
work that way. The problem is more akin to Apple's introduction of 'Sticky Keys'
in OS 8 or 9; also click-hold menus are a rarity in OS X and are mostly seen in
finder actions than in applications. 

Mike, Josh and Simon's final comments seem perfectly right - it's a mac platform
bug on a platform that has changed substantially since this was acceptable
behaviour for a widget.

Comment 51

[Mike Connor [:mconnor]]

Comment on attachment 189291 [details] [diff] [review]
fix v1.0

I would rather see this wrapped in an #if 0 block so that embeddors can easily
find and re-enable if needed, unless we're removing the entire impl.

r=me on disabling this.

Comment 52

[Josh Aas]

Comment on attachment 189291 [details] [diff] [review]
fix v1.0

I will wrap it in an "#if 0" when it is checked in.

Tough call, but I think this is best.

Comment 53

[Asaf Romano (gone)]

(In reply to Josh Asa, comment #48)

> (Seamonkey can ifdef it on if they like, I never suggested removing the
> implementation code)

Fork core parts isn't a good plan, especially if xulrunner-seamonkey is stil in
their todo list.

Comment 54

[Benjamin Smedberg]

I feel strongly that we are making a serious mistake with this major UI change
that will confuse the physical habits of any longtime mac browser user... hell,
I've been using ffox on mac for about three months and the only way I know to
open a link in a new tab is to click-hold the link.

Let's fix the problem in a much more targeted way (fix the
context-menu-in-context-menu problem) rather than hitting this with a UI cannon.

Comment 55

[Mike Beltzner [:beltzner, not reading bugmail]]

As I understand it, while the issue was originally just the back/forward thing
(click-hold acts both as a single-back *and* a show the drop-down action) it
expanded to cover the fact that:

- the implementation is buggy (see comment 37 and comment 41) 
- click-hold to get context menus is non-standard for OS X
- click-hold to get context menus isn't used in PC/Linux (and thus non-standard
for the browser itself)

Assuming that Mac users interact with other applications, they should be
familiar with the standard way to get a context menu (ctrl+click or right click).

Comment 56

[Josh Aas]

Furthermore, the default Mac OS X browser (Safari), used by most of the people
who are novice enough not to know how to get context menus, does not support
click-hold context menus.

We are not "hitting this with a UI cannon" - this is just the time to get rid of
click-hold, and this bug happens to be when we want to do it. This isn't the
first time we've considered getting rid of click-hold. It isn't about just this bug.

Comment 57

[Benjamin Smedberg]

Sure, it's not the first time, and it's not the last time, and we should reject
it every time, at least until powerbooks come with two mouse buttons.

The mac HIG is not the controlling concept here, it is the physical memory of
our users: click-hold context menus are a long-standing behavior that was
inherited from NS4 -> mozilla -> firefox and we shipped ffox 1.0 with it. That
makes the change a major UI cannon regardless of the bugs that it may fix.

Unless somebody is able to come up with empirical usability testing showing that
the vast majority (more than 95%) of users do not use click-hold context menus,
we should not simply treat this as a given "match the HIG" kind of change, but
rather as the truly revolutionary change that I believe it is.

Comment 58

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm all for supporting muscle memory, which is why I'm saying we should support
the HIG definition of what to do with click-hold actions in the OS X UI. That's
what HIGs are for: to make sure that all apps on a platform interpret certain UI
actions the same way.

We currently *do* support ctrl+click for context menus, which is the OS X way of
dealing with the one-mouse button issue. If you want to say that click-hold is a
nice optimization beyond that, then it should be a nice optimization available
for *all* platforms and we should treat it as such. Otherwise we end up in a
situation where we're supporting a UI gesture that is not standard either within
the target platform or across all target platforms. Boo.

Apple's got this thing about single-mouse buttons being simpler, and they've got
their own way of dealing with context menus. (Your suggestion of a usabiltity
test is interesting, but to be a fair analysis of the issue, it should be with
*all* OS X applications, not just our browser, and ask users if they find one
mechanism more convienient than another.)

Comment 59

[Josh Aas]

Apple has 1-button mouses to this day largely because context menus are bad UI
to rely on. On operating systems that have 2-button mouses, context menus can
get very out of control, sometimes containing hundreds of items. Just wanted to
make that clear.

As for the physical memory of our users... Firefox is one of the ONLY apps on
Mac OS X that uses click-hold, which isn't very conducive to training physical
memory for context menus on the whole. It is doubtful that users are not aware
of other ways to open context menus as Firefox is probably not the only app in
which they want to use click-hold menus. In your case, you'd have figured
something else out if they didn't exist. I get along just fine using context
menus on my PowerBook, and I don't use click-hold. Why? Because I use the rest
of Mac OS X in the same way. Aside from the fact that I use a standard way to
access context menus, click-hold (waiting to be able to do something) is really
a slow way to operate. It is a bad habit worth breaking if you can figure out an
alternative.

As for your specific PowerBook case... notice that you can only have 1 hand on
the trackpad at a time. Nobody uses 2 hands to do that. Normally your other hand
is free to be on the keyboard, conveniently over the control button that brings
up context menus. It makes perfect sense how this works on a PowerBook from a
physical space angle, and it is much faster.

Comment 60

[Benjamin Smedberg]

Josh and Mike, if we were making a clean-slate decision, I agree with everything
you said. If we had not already released years of mozilla and ffox 1.0 I would
say absolutely, go ahead. But we have, and I believe a not-insignificant number
of users have ingrained ways of doing things with our browser. With an
established application, I believe that past history trumps both the HIG and
idealism any day.

Comment 61

[Matthew T (active 1999-2002)]

Safari, like Firefox, and the late MSIE/Mac before it, and NS4 before that, 
has click-and-hold menus for the Back and Forward buttons. So if you abolish 
such menus everywhere you'll just be replacing one bug with another. And if 
you abolish them just for links, you're not addressing this bug at all.

Comment 62

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #61)
> Safari, like Firefox, and the late MSIE/Mac before it, and NS4 before that, 
> has click-and-hold menus for the Back and Forward buttons. So if you abolish 

This goes back to the original intent of the bug, I think, and I'm not actually
arguing against removing click-and-hold as a mechanism of getting to the
drop-down menu on the back/forward buttons, since (as you mention) every other
mac-based browser does this. I'd be fine with (for back/forward buttons) single
click = one step, click-and-hold = show drop down, and when drop-down is shown,
if no entries are selected then nothing happens.

What I am saying we should get rid of, however, is click-and-hold acting as a
way of invoking the context-menu anywhere within the window. Perhaps this bug
really needs to be forked: this one to deal with click-and-hold for
back/forward, and a new one to deal with click-and-hold as an alternate route to
the context menu.

Comment 63

[Ben Goodger (use ben at mozilla dot org for email)]

Caveat: 

At work (with my Powermac G5) I use a two button mouse most of the time, and
mostly on Windows. I do use Mac a fair bit though. 

Now, 

- At home (with my other Powermac G5) I use a Apple bluetooth wireless mouse,
and it's convenient not to have to push the Ctrl button to open a context menu
while browsing. It makes me feel faster. 
- You can argue about the merits of making those functions exposed in the
context menu easier to do in other ways, but I don't see that these use cases
have been identified or resolved. 
- What Benjamin said. Not just wrt 1.0, but other browsers on the Mac since the
dawn of creation.

Mike - your argument that other apps don't do this isn't 100% applicable here,
because most other apps on OS X don't make extensive use of the context menu.
You could argue that that's a flaw with the browser's UI (and I'm sure Matthew
will) but if that's the case, then we need to come up with some other solution
for those functions.

Comment 64

[Matthew T (active 1999-2002)]

When I originally reported this bug, I assumed that we would eventually 
return to a world where men were men, buttons looked like buttons, and the 
button and menu parts of a menubutton were obviously different things, so 
clicking on the button part would act like a button whether you clicked it 
for 0.99 seconds or 1.01 seconds -- reliability over simplicity. In Safari 
(and Mail 2.0) buttons look like buttons, but (as in NS4 and MSIE) the 
button and menu parts of a menubutton are not different things, so (as in 
NS4 and MSIE) click-and-hold is appropriate -- simplicity over reliability. 
In Firefox the menu and button parts are separate, but they don't look 
separate, *and* the button part acts with click-and-hold, which is (IMHO) 
the worst of both worlds.

If retaining the current appearance+behavior, the way to fix this bug is to 
make click-and-hold apply just to the button, not to the entire menubutton.

Comment 65

[Cecelia S]

I use drag lock with my touch pad on my Powerbook (and iBook before that). I'd
just be happy if holding a click on the scroll widgets of the Mail message
window didn't invoke a contextual menu. (Should this be a seperate bug?)
Control-click works there too.

Comment 66

[Josh Aas]

In any case, I recommend taking this off the blockers list.

Comment 67

[Asaf Romano (gone)]

Attachment: patch for the bug itself

(Can we move the forever discussion to a new bug?)

Comment 68

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #67)
> (Can we move the forever discussion to a new bug?)

Done. See bug 301758 for the great "should we support click-and-hold context
menus everywhere?" debate! I'll add this bug's cc list to that one.

Comment 69

[jhp (no longer active)]

Comment on attachment 190157 [details] [diff] [review]
patch for the bug itself

Hmm, this didn't seem to fix either issue for me, when I applied the patch.  It
seems like it should fix the issue of click-hold on URL bar arrow displaying
both the history and the toolbar context menu (but it didn't fix it for me). 
But I don't see how this patch would fix the original issue of click-hold on
back arrow showing history, and also going back when releasing mouse button.

Comment 70

[jhp (no longer active)]

Comment on attachment 190157 [details] [diff] [review]
patch for the bug itself

OK, so this patch gets rid of the double-menus when doing a click-hold on the
menu part of the back/forward buttons.	Cool.

But it still doesn't address the first bug in the summary, that of going back
one page when releasing the mouse.  That should be fixed in this bug, too.

Comment 71

[Asaf Romano (gone)]

Since this bug is already useless enough, i moved the remaining issue to bug 302098.

Comment 72

[Asaf Romano (gone)]

Checking in nsEventStateManager.cpp;
/cvsroot/mozilla/content/events/src/nsEventStateManager.cpp,v  <-- 
nsEventStateManager.cpp
new revision: 1.592; previous revision: 1.591
done

Comment 73

[Matthew T (active 1999-2002)]

Verified fixed, Deer Park Alpha 20050810, OS X 10.3.9.

> other apps on OS X don't make extensive use of the context menu. You could
> argue that that's a flaw with the browser's UI (and I'm sure Matthew will)
FWIW, Ben, I won't; I stand by the INVALID resolution of bug 34357.

Comment 74

[Stefan [:stefanh]]

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

Comment 75

[Stefan [:stefanh]]

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

Comment 76

[Stefan [:stefanh]]

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

Comment 77

[Stefan [:stefanh]]

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