Event Handling Question

[Louis]

I was trying to display a custom context menu in javascript. I wanted to
capture a right mouse click.

I added an eventListener to a "div" like this..

element,addEven tListener ("click", myfunc, true);

When I tried to debug it, it seems to react fine to a left mouse click,
but it totally ignores the right mouse click.

Can somebody please explain why?

(When I changed the "click" to "mousedown" , it seems to work fine for
both right mouse button as well as the left.)

Thank you.

[David Mark]

On Aug 6, 4:37 am, Louis <t051...@hotmai l.comwrote:

I was trying to display a custom context menu in javascript. I wanted to
capture a right mouse click.

I added an eventListener to a "div" like this..

element,addEven tListener ("click", myfunc, true);

When I tried to debug it, it seems to react fine to a left mouse click,
but it totally ignores the right mouse click.

Can somebody please explain why?

(When I changed the "click" to "mousedown" , it seems to work fine for
both right mouse button as well as the left.)

You sort-of answered your own question. Certainly onmousedown is not
appropriate to display a context menu (onmouseup is correct.) You
also need oncontextmenu for some browsers.

And BTW, Opera won't work like this at all, so you need an alternative
(eg ctrl-left, middle, etc.)

[Thomas 'PointedEars' Lahn]

Louis wrote:

I was trying to display a custom context menu in javascript. I wanted to
capture a right mouse click.

I added an eventListener to a "div" like this..

element,addEven tListener ("click", myfunc, true);

The first comma is probably only a typo. And are you sure you want/need
event capturing (the third argument being `true')?

When I tried to debug it, it seems to react fine to a left mouse click,
but it totally ignores the right mouse click.

Can somebody please explain why?

It is not supposed to. The `click' event fires, in my words, when the
activation key (usually Return/Enter) is pressed and the element has the
focus, or when the primary pointing device button (with a mouse, the left
button unless configured for left-handed people, provided there is a right
button at all) is pushed down and released (i.e. it is clicked) when the
pointer is positioned over the element.

W3C DOM Level 2 Events specifies the event as follows:

,-<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Eve nts-eventgroupings-mouseevents>
|
| click
| The click event occurs when the pointing device button is clicked over
| an element. A click is defined as a mousedown and mouseup over the same
| screen location. The sequence of these events is:
|
| mousedown
| mouseup
| click

Note that the specification says "the pointing device button", which means
there is no provision for more than one button.

(When I changed the "click" to "mousedown" , it seems to work fine for
both right mouse button as well as the left.)

Works as designed. However, different to the `click' event, `the
`mousedown' event fires already when the key or button is pushed.

You really should leave the function of the secondary button as it is.
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[korisu]

On Aug 6, 4:27 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

You really should leave the function of the secondary button as it is.

I disagree on this point. I do acknowledge that it's bad design to,
say, disable the secondary button across your entire site, as that
would change the behavior of the page from the user's expected
behavior, but from within a designated and controlled area, using the
events as specified by the W3C should be completely allowed. That is
to say, the function of the secondary (and tertiary!) button may
change with respect to the page's intended use of the mouse as the
main interaction device.

For example, say I'm making a Minesweeper clone in DHTML. The right-
click button is by far the most intuitive interface for performing
'safety' actions on the grid, and right-click+left-click is the
accepted, familiar way to "clear" a surrounding group of squares on
the grid. However, in the W3C model, there is no native way of
detecting multiple mouse buttons used in a mouse event, and without
reliable preventDefault behavior, I'm likely to trigger any one of
several gestures in Opera or Firefox. (And that's after I force my
Opera-driven users to upgrade to 8.5+ and turn on "Allow script to
receive right-clicks" in a menu buried in Preferences.)

Or say I'm creating an interactive tab bar for a client's intranet
application, and they'd like to leave browser choice for their users
open for choice. Shouldn't I be able to duplicate the tab behavior of
any other tabbed browser, where middle-click closes the tab? Well,
there's no way (I've found) for preventing the default 'turn on the
scroll anchor' on mousedown. (Assuming I could get Firefox to
recognize the middle-click in the first place.)
These seem like simple implementations of a pretty clearly-defined
standard, that browser manufacturers have decided to straight-up deny
in what I assume to be the name of "protecting their users from
malicious [read: annoying] web authors". The days of preventing a
dozen popup windows from Geocities are long since over; these simple
features should be given back to Web authors. If they choose to abuse
them, there's no real harm that can be done to the page or the user's
client due to other Javascript security measures, and if they affect
the user's experience adversely enough, the users will leave and those
practices will die with the author's business.

All I'm saying is, I'd really wish browsers would respond to the event
handlers I'm setting on them, and when I say preventDefault, I mean
prevent the damn default.

[Thomas 'PointedEars' Lahn]

ko****@gmail.co m wrote:

On Aug 6, 4:27 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

>You really should leave the function of the secondary button as it is.

I disagree on this point. I do acknowledge that it's bad design to,
say, disable the secondary button across your entire site, as that
would change the behavior of the page from the user's expected
behavior, but from within a designated and controlled area, using the
events as specified by the W3C should be completely allowed.

But the Web is no such area. For example, have you ever used mouse
gestures? They are usually triggered by dragging with the secondary button.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8************ *******@news.de mon.co.uk>

[korisu]

On Aug 21, 11:51 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

But the Web is no such area. For example, have you ever used mouse
gestures? They are usually triggered by dragging with the secondary button.

I use mouse gestures every day. If you had taken the time to read the
rest of my post, you'd notice this:

without reliable preventDefault behavior, I'm likely to trigger any one of several gestures in Opera or Firefox.

Gesture functionality at the browser level is the default behavior. If
my script says "prevent that behavior when the event happens within
this part of my page", then the browser should respect that command as
issued by the script. After all, isn't that what preventDefault( ) is
for?

[Thomas 'PointedEars' Lahn]

korisu wrote:

On Aug 21, 11:51 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

>But the Web is no such area. For example, have you ever used mouse
gestures? They are usually triggered by dragging with the secondary button.

I use mouse gestures every day. If you had taken the time to read the
rest of my post, you'd notice this:

>without reliable preventDefault behavior, I'm likely to trigger any one
of several gestures in Opera or Firefox.

I read that, and it is still irrelevant.

Gesture functionality at the browser level is the default behavior. If
my script says "prevent that behavior when the event happens within
this part of my page", then the browser should respect that command as
issued by the script. After all, isn't that what preventDefault( ) is
for?

No. And do you realize that this method is not universally supported?
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8************ *******@news.de mon.co.uk>

[korisu]

On Aug 30, 2:40 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

No. And do you realize that this method is not universally supported?

You're wrong; that is what preventDefault is supposed to do. I realize
that IE doesn't use preventDefault, but then again, this problem
doesn't exist in IE - it does what I tell it to, and provides me with
useful feedback. My issue concerns the browsers that claim to have
full support for the W3C Events specifications.

>From the W3C DOM Level 2 Events specification:

preventDefault
If an event is cancelable, the preventDefault method is used to
signify that the event is to be canceled, meaning any default action
normally taken by the implementation as a result of the event will not
occur. If, during any stage of event flow, the preventDefault method
is called the event is canceled. Any default action associated with
the event will not occur. Calling this method for a non-cancelable
event has no effect. Once preventDefault has been called it will
remain in effect throughout the remainder of the event's propagation.
This method may be used during any stage of event flow.

[Thomas 'PointedEars' Lahn]

korisu wrote:

On Aug 30, 2:40 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

>No. And do you realize that this method is not universally supported?

You're wrong;

I'm not. preventDefault( ) is not intended as a method to cripple user agents.

that is what preventDefault is supposed to do.

It is still not universally supported.

I realize that IE doesn't use preventDefault, but then again, this
problem doesn't exist in IE [...]

Apparently you know only IE and not IE.
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>