FAQ Topic - How do I disable the right mouse button?

F

FAQ server

-----------------------------------------------------------------------
FAQ Topic - How do I disable the right mouse button?
-----------------------------------------------------------------------

The oncontextmenu intrinsic event is the only safe and reliable
method. Of the other approaches often presented, most depend on
an alert box interrupting the process and rarely work. Note that
oncontextmenu is a non-standard event and is not supported on
all browsers.
` <body oncontextmenu="return false"> `


===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://jibbering.com/faq/index.html.
The FAQ workers are a group of volunteers. The sendings of these
daily posts are proficiently hosted by www.pair.com.
 
T

Thomas 'PointedEars' Lahn

FAQ said:
The oncontextmenu intrinsic event

As I have pointed out in my still unanswered e-mail to both current FAQ
maintainers about 20 days ago (along with other suggestions and comments),
that wording is wrong. `oncontextmenu' is a proprietary event handler,
not an intrinsic event as defined by and in the HTML 4.01 Specification:

http://www.w3.org/TR/html401/interact/scripts.html#events
is the only safe and reliable method.

As I also have pointed out, because it is proprietary and not standardized,
it runs the risk of being not well supported, if supported at all, and so it
is not a safe and reliable method at all.
Of the other approaches often presented, most depend on
an alert box interrupting the process and rarely work. Note that
oncontextmenu is a non-standard event

It is a non-standard (i.e. proprietary) event *handler*. The corresponding
event would be `contextmenu'. It is just that the MSDN Library is unable to
make that important distinction to date (when MS begins to implement DOM
Level 2+ Events, they will finally have to.) In that sense, the HTML 4.01
Specification which uses the same (wrong) terminology has been updated by
the W3C DOM Level 2 Events Specification as indicated by the included note
in the aforementioned subsection of HTML 4.01:

http://www.w3.org/TR/DOM-Level-2-Events/
and is not supported on all browsers.

There is the all-too-obvious contradiction to the above statements.


PointedEars
 
B

Bart Van der Donck

Randy said:
Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:


My personal vote: The entry is wrong from start to finish. The question
being:

"How do I disable the right mouse button?"

And the only technically correct answer can only be:

"You can't".

My personal vote is to keep

<body oncontextmenu="return false">
 
D

Dr J R Stockton

In comp.lang.javascript message said:
Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:

My personal vote: The entry is wrong from start to finish. The question
being:

"How do I disable the right mouse button?"

And the only technically correct answer can only be:

"You can't".

A most irresponsible suggestion. Of course a script can disable the
right mouse button, or at least prevent it showing the usual menu. One
condition is sufficient, though probably not entirely necessary : that
the browser be IE6 running in XP sp2.

For me, <body oncontextmenu="return false"> disables it in IE6,
but not in Opera 9.23.

Therefore, an acceptable answer giving that code must state clearly that
it works in some but not all browsers.

Consider -
User, viewing page : The right mouse button does not now work!
Adviser, reading FAQ : It cannot be disabled; it must be broken.
 
D

Dr J R Stockton

In comp.lang.javascript message said:
Dr J R Stockton said the following on 9/4/2007 6:16 PM:

It isn't a "suggestion", it is fact. You can not disable my right mouse
button. Although you are welcome to try to prove me wrong.

The word you need is "cannot", implying impossibility. Use of "can not"
means a lack of inevitability. The distinction is important to the
literate.

No it doesn't. Nor can it. Remember that this discussion got started
because Thomas wanted it semantically/technically correct.

Don't respond in the middle of a statement of that nature.
It doesn't do that either. Reverse the mouse buttons and you can still
get that menu if you disable the right mouse button (try it).


Does that imply that it won't work in IE7 then?

No. It means what it says.
That is because Opera does not allow mucking with the contextmenu's
and/or mouse actions. And, the above code has nothing to do with the
right mouse button. It prevents the context menu from showing.


And it doesn't have to say that it is useless, easily circumvented, and
violates accessibility guidelines?

No; if I had meant that, I would have written so,
You can reverse the mouse buttons in Windows via the Control Panel.
(Control Panel>Mouse>Button Configuration). Mostly it is for left
handed people. You have just made navigation in your page impossible if
you "disable the right mouse button".

That effect is generally undesirable (though navigation without a mouse
is possible, especially on a page designed for it). But you have now
changed your mind, admitting that it can be disabled.

Perhaps when you write "You can't", you mean "You mustn't".



Probably the Question should be changed to something for which an
accurate, useful, and reasonably brief answer can be given.

If you want to answer "How can I protect my source from being copied?",
then "ask" that question. The answer can include mention of said
button, for those who search for that.
 
T

Thomas 'PointedEars' Lahn

FAQEditor said:
FAQEditor said the following on 9/4/2007 8:43 AM:

Have you tried to resend that email? I have not yet received any from you.

Sorry, I'm currently too busy doing my (RL) job.


PointedEars
 
T

Thomas 'PointedEars' Lahn

FAQEditor wrote at 2007-09-04 08:43 GMT-0500:
Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:

20 days ago was about the time I changed the email address in the FAQ to
the current one. If you sent an email to the old address then it would
explain why I haven't received it. If you sent it to (e-mail address removed)
then I honestly do not know why I have not received it unless it didn't
have FAQ in the Subject line of the email. If you would, please forward
it or re-send it to (e-mail address removed) and make sure the Subject Line
has FAQ in it so that the spam filter doesn't catch it by mistake.

Although personally, I would prefer that comments regarding the FAQ -
and its contents - be posted to the group so that it can be reviewed and
commented on by the group.

Here you are:

---------------------------------------------------------------------------
Message-ID: <[email protected]>
Date: Wed, 15 Aug 2007 17:32:12 +0200
From: Thomas 'PointedEars' Lahn <******************>
Reply-To: Thomas 'PointedEars' Lahn <*******************>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6)
Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: (e-mail address removed)
CC: (e-mail address removed)
Subject: Suggestions for the comp.lang.javascript FAQ
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=sha1; boundary="------------ms000907080800040308070406"

This is a cryptographically signed message in MIME format.

--------------ms000907080800040308070406
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hello Randy,
Hello Jim,

here are some of my comments to and suggestions for the cljs FAQ and the
FAQ Notes.

Regarding the FAQ:

| 4.24 I have <a href="javascript:somefunction()"> what ... ?
|
| Whatever the rest of your question, this is generally a very bad use of
| the javascript pseudo protocol. It was designed so that a function could
| return a new page.

Replace "page" with "HTML document" (s/page/HTML document/)

| For example: javascript:"<p>Hello</p>" . Using it simply to call a
| function when a link is clicked causes an error in user agents that do not
| support javascript, or have javascript disabled.

That is *not* what happens. Instead, the following cases can occur:

A) No script support or no support for the proprietary `javascript:':

Error message (e.g. in IE 4 with enabled script support)

B) Disabled script support (that requires script support being present,
and usually implies support for "javascript:"):

Animations and other multimedia elements stop working.
Nothing else happens.

C) Script support present and enabled:

Animations and other multimedia elements stop; further accesses
to `location' may fail; other (non-script) links may fail.
Reason: there is no base for (relative) URIs references anymore.

(reported several in de.comp.lang.javascript)

| 4.26 How do I detect Opera/Netscape/IE?

Iff necessary, Netscape 4.x can currently be detected by evaluating
document.layers.

Iff necessary, Opera can currently be detected by evaluating window.opera.

| 4.27 How do I disable the right mouse button?
|
| The oncontextmenu intrinsic event is the only safe and reliable method.

`oncontextmenu' is _not_ an intrinsic event (as specified using this term
starting in HTML 4.01). Instead, it is a (currently) *proprietary* event
_handler_. Whether that could be considered "safe and reliable" is beyond me.

| Note that oncontextmenu is a non-standard event and is not supported on
| all browsers. <body oncontextmenu="return false">

A clear statement that this is not Valid HTML and, more important, not Valid
XHTML unless the attribute is defined in an internal subset, is missing.
Not Valid XML-based markup can make a validating parser to stop parsing
where the first error occurs.

| 4.28 How do I change the confirm box to say yes/no or default to cancel?

It should be added that OK/Cancel may lead to confusion if used with the
wrong question:

Do you want to cancel this operation?

[ OK ] [ Cancel ]

Now what? :)

| 4.37 How do I POST a form to a new window?
|
| You use the target attribute on the form, opening a window with that name
| and your feature string in the onsubmit handler of the FORM.
|
| <form ... target="wndname"
| onsubmit="window.open('',this.target,'features');return true;">

This should be changed so that it is made clear that an omitted `action'
attribute renders the markup not Valid.

<form action="..." target="..."
onsubmit="window.open('', this.target, 'features'); return true;">

window.open() is also a host object's method that should be tested for, and
one that works asynchronously (if it works). The FAQ should advise that a
wrapper method that does the test and maybe submits the form on timeout is
better than "literally" including the example in one's markup.

| 4.38 How do I download a page to a variable?
|
| Within a web-page, you need to either use java, or the XML HTTP Request
| object, see:

s/a web-page/an (X)HTML document/

I don't see a valid reason why _J_ava should be mentioned first here, or
mentioned at all for that matter. If it is mentioned, one could mention
any programming language that allows to make HTTP requests, especially
server-side (e.g. PHP).

IMHO, mentioning "java" only has the potential to deepen the confusion of
the reader between Java and JavaScript.

| 4.42 How do I open a new window with javascript?
|
| New windows can be opened on browsers that support the window.open
| function and are not subject to the action of any pop-up blocking
| mechanism with code such as:-
|
| if(window.open){
| wRef = window.open("http://example.com/page.html","windowName");
| }

Either none or a better feature test should be advised, such as

if (/\b(function|object)\b/i.test(typeof window.open) && window.open)
{
wRef = window.open("http://example.com/page.html", "windowName");
}

| 4.43 How do I get my browser to report javascript errors?
|
| [...]
| There is also a Firebug extension for Mozilla based browsers:
| http://www.getfirebug.com/

It should be noted that there is the Firebug console for IE and Opera which
may help with debugging scripts there.

[SN: The online resources listed in subsection 3.2 include links to
debuggers. These should be referred to in 4.43 (as well).]

| 4.44 What is AJAX?

s/page/document/

Probably there are more instances of this.


Regarding the FAQ Notes:

- http://www.jibbering.com/faq/faq_notes/clj_posts.html

| Additional Reading

Sometimes the <~> character is percent-encoded (%7E), sometimes it is not.
RFC3986, section 2.3, recommends *against* encoding it.

| Related draft proposals / work in progress:-

The links are broken. You should employ a tool such as
http://validator.w3.org/checklink before announcing a
new FAQ/FAQ Notes version.

- A better URI management is indicated, maybe using Content Negotiation.

For example, why not

http://www.jibbering.com/faq/notes/
and
http://www.jibbering.com/faq/notes/postings

instead of

http://www.jibbering.com/faq/faq_notes/faq_notes.html
and
http://www.jibbering.com/faq/faq_notes/clj_posts.html?


Thank you for taking the time. I am looking forward to your reply.


Regards,

PointedEars

[snipped PKCS7 signature]
---------------------------------------------------------------------------
 
D

David Mark

Dr J R Stockton said the following on 9/4/2007 6:16 PM:

Right. It's the wrong question. It should be "How do I disable the
context menu."
It isn't a "suggestion", it is fact. You can not disable my right mouse
button. Although you are welcome to try to prove me wrong.


No it doesn't. Nor can it. Remember that this discussion got started
because Thomas wanted it semantically/technically correct.


It doesn't do that either. Reverse the mouse buttons and you can still
get that menu if you disable the right mouse button (try it).

This is not true. Software applications get the correct logical
button, regardless of which physical button generated the event. I
just tested it with my context function. I would have been shocked if
it failed for IE as the event is "contextmenu" and there is no need to
detect the button in JavaScript. It didn't break in the other agents
that use mouseup and button detection either. For the record, I have
tested in IE5, IE5.5, IE6, IE7, Firefox 2, Netscape 9, Opera 9 and
Safari Beta on Windows and all work with this logic in a contextmenu/
mouseup handler:

e = e || global.event;
if ((e.which == 3 || e.button & 4) || e.type == 'contextmenu') ...

If memory serves me right, at least one non-IE browser (Opera I think)
supports the contextmenu event. So you have to deal with cases where
both events fire. I believe the above works for Mac's as well,
despite the fact that most (all?) have a single mouse button. IIRC,
to generate a context click requires holding the button for a few
seconds. Certainly it should work in Mac IE if it supports the
contextmenu event.

There just is no one-line solution that is suitable for a FAQ entry on
how to disable the context menu. And there is definitely no answer
for how to disable a physical right click (or even a logical context
ckick.)

And I think it should be noted that it is insane to handle context
clicks unless you implement a custom context menu (and it is a very
rare case where that is appropriate.)
 
D

Dr J R Stockton

In comp.lang.javascript message said:
Thomas 'PointedEars' Lahn said the following on 10/6/2007 6:06 PM:


That is true. But, is it a good idea to tell how to detect a browser in
an entry that attempts to discourage the practice of browser detecting?


I've just come across a case in which browser detecting may be
necessary.

Fetch <URL:http://www.merlyn.demon.co.uk/js-a.htm> (5kB); press the
button, and wait 0.07 minutes. At that time, presuming the longer input
field is empty, document.body.style.backgroundColor = "red" should
be executed.

In MS IE 6 and in FF 2.0.0.7, that immediately turns the background
visibly red.

In Opera 9.23, nothing visible happens until there is some other reason
to re-draw all or part of the window. Since the colour-change is what
the code is *for*, ... .

Is there a method that explicitly calls for a re-paint?
 
D

David Mark

In comp.lang.javascript message <[email protected]>,



I've just come across a case in which browser detecting may be
necessary.

Fetch <URL:http://www.merlyn.demon.co.uk/js-a.htm> (5kB); press the
button, and wait 0.07 minutes. At that time, presuming the longer input
field is empty, document.body.style.backgroundColor = "red" should
be executed.

In MS IE 6 and in FF 2.0.0.7, that immediately turns the background
visibly red.

In Opera 9.23, nothing visible happens until there is some other reason
to re-draw all or part of the window. Since the colour-change is what
the code is *for*, ... .

Is there a method that explicitly calls for a re-paint?

Not really, but you are on the right track. Play around with setting
styles of other elements on the page and see if it has any effect.
Also, try the documentElement and see if it works any better. Or
change the body's class name instead of setting the inline style. One
thing that will almost surely fix it is to navigate to an anchor (put
it right above the clock interface.) Actually, that seems like a
good solution as the user may have scrolled away from the clock in the
interim.

To eliminate suspects, did you try taking the timer out of the
equation?

Try to find a safe solution that works for everything. Checking for
window.opera is the last thing you want to do. What would you do
differently if it returns an object? Assuming you can identify a
workaround that is harmful to other browsers, who is to say that older
or newer versions of Opera wouldn't be affected by it?

I have never seen this, but then I never tried to change the body's
background color on a timer. I can tell you that I have code that
switches style sheets and it affects the background color of the body
(and/or documentElement) immediately in Opera 9.
 
D

David Mark

David Mark said the following on 10/7/2007 7:10 PM:







Can you, or have you, duplicated it in Opera9? I can't is why I ask. I
get the same behavior in IE7, FF2.0, Opera9.22 and Opera9.23

I duplicated it in Opera 9.21 and also found a workaround. Changing
the className of the body updates the color, regardless of what you
change it to. The best solution is to define the color schemes for
the clock in CSS classes. If the colors must be hard-coded into the
script, then you can change the body class name to anything that isn't
defined in the style sheets. In testing I changed it to "test1" after
the yellow event and "test2" after the red.
 
D

David Mark

David Mark said the following on 10/7/2007 8:04 PM:







Makes me wonder what I might have set differently for it to work for me.
The 9.23 was a default install (I installed 9.23 just to test this with).

It probably is not a difference in the Opera installation. A refresh
problem like that could be affected by differences in display drivers,
operating systems, etc. I'm sure the Opera software tried to repaint
the window, but for some low-level reason it didn't happen.

Windows Safari Beta has lots of issues like this. As I recall, older
versions of Netscape/Mozilla/Gecko can do this when setting
innerHTML. Typically, setting a className or the display property of
the affected element fixes it. I recall a particularly bad script
that sniffed for Gecko browsers and then set an interval to constantly
change the display property of some dummy element.
 
D

David Mark

David Mark said the following on 10/7/2007 8:34 PM:







Then detecting Opera won't detect the problem :-\

That was my original point. In the end, the solution is suitable for
all browsers, so there is no need to detect the problem at all.
That could be easy to test for, I think. Wait 3 seconds and check the
backgroundColor property and if it is red.....

Opera will certainly return red for the style property, regardless of
what state the window is in. The browser changed the property, but
something low-level didn't refresh the client area of the window.
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
legroups.com>, Sun, 7 Oct 2007 17:34:42, David Mark
It probably is not a difference in the Opera installation. A refresh
problem like that could be affected by differences in display drivers,
operating systems, etc. I'm sure the Opera software tried to repaint
the window, but for some low-level reason it didn't happen.

I got the same effect with Opera on an entirely different PC. Both are
running XP, but one is a generic desktop with a CRT and the other is an
Acer LCD laptop.

Given what one sees if one half-hides the Opera window before it fires,
and then looks, Opera is indeed painting something red (i.e. doing more
than just setting a variable or a passive property) but it's not
persuading Windows to actually show it.

A pragmatical crude workround in this case is to put anything other than
an empty string in the larger input field.

The simplest page with one button directly doing the command works in
Opera; one that wraps the command in exec(" ") does not. When
testing without a timer, one really wants a means of executing on an
already-loaded page without doing anything that rewrites anything, to be
certain that the test is sound.


But I don't absolutely need a way of getting it to work in Opera; the
page is primarily for my own use, and using IE is an adequate fix.

However, using
if (X) { window.location = X }
else { document.body.style.backgroundColor = "red"
document.body.className = "O" + Opera++ }
fixes it. There, Opera++ or similar is needed so that subsequent
firings give a different Class.

Thanks.

Now, however, in Opera only, when the background goes red most of the
form contents leap to the left, returning a second later.


Page js-a.htm is a temporary for js-alarm.htm, which is not there any
more for reasons of bandwidth (it *could* conceivably be popular); it
therefore now has code to prevent it from working when loaded from the
Web server (but a copy will work); and so that readers can currently
test it the effective part of that code, in SetJob, is commented out
/pro tem/.


But the original point, relating to the feature detection discussion
earlier in thread, is that whether or not the visible screen is actually
written is a feature undetectable by code - and, if there were no
workround acceptable to all browsers, browser detection would be
justified.
 
D

David Mark

In comp.lang.javascript message <[email protected]
legroups.com>, Sun, 7 Oct 2007 17:34:42, David Mark
<[email protected]> posted:




I got the same effect with Opera on an entirely different PC. Both are
running XP, but one is a generic desktop with a CRT and the other is an
Acer LCD laptop.

I did too, but Randy didn't. Who knows what the difference is?
Given what one sees if one half-hides the Opera window before it fires,
and then looks, Opera is indeed painting something red (i.e. doing more
than just setting a variable or a passive property) but it's not
persuading Windows to actually show it.
Right.


A pragmatical crude workround in this case is to put anything other than
an empty string in the larger input field.

To make it redirect? That short-circuits the whole color update. I
guess that qualifies as a (very) crude workaround.
The simplest page with one button directly doing the command works in
Opera; one that wraps the command in exec(" ") does not. When

You lost me there. But I should note that neither the yellow nor the
red updates worked here (without the className updated.)
testing without a timer, one really wants a means of executing on an
already-loaded page without doing anything that rewrites anything, to be
certain that the test is sound.

But I don't absolutely need a way of getting it to work in Opera; the
page is primarily for my own use, and using IE is an adequate fix.

However, using
if (X) { window.location = X }
else { document.body.style.backgroundColor = "red"
document.body.className = "O" + Opera++ }
fixes it. There, Opera++ or similar is needed so that subsequent
firings give a different Class.

In testing I set it to "test1" on the yellow update and "test2" on
red. Are you not having a problem with yellow?
Thanks.

Now, however, in Opera only, when the background goes red most of the
form contents leap to the left, returning a second later.

That I didn't see. Try using the documentElement instead of the body
and see if the same thing happens.
Page js-a.htm is a temporary for js-alarm.htm, which is not there any
more for reasons of bandwidth (it *could* conceivably be popular); it
therefore now has code to prevent it from working when loaded from the
Web server (but a copy will work); and so that readers can currently
test it the effective part of that code, in SetJob, is commented out
/pro tem/.

But the original point, relating to the feature detection discussion
earlier in thread, is that whether or not the visible screen is actually
written is a feature undetectable by code - and, if there were no
workround acceptable to all browsers, browser detection would be
justified.

If there were no universal workaround and you could be sure that an
Opera-specific workaround would not break future (or past) versions of
Opera, considering that Opera has an object to detect (as opposed to
sniffing the user agent string), then looking at window.opera wouldn't
be out of the question. The first condition is a mighty big if though
as I have never run into such a case in scripting. CSS workarounds
for IE are another story.
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
oglegroups.com>, Mon, 8 Oct 2007 16:06:41, David Mark
You lost me there. But I should note that neither the yellow nor the
red updates worked here (without the className updated.)

Only the red has ever failed here.

<input type=button // simplest
onClick="document.body.style.backgroundColor='red'">

<input type=button // with exec
onClick="exec(\"document.body.style.backgroundColor='red'\")">

In testing I set it to "test1" on the yellow update and "test2" on
red. Are you not having a problem with yellow?

No, only ever with red, which is at timeout.

That I didn't see. Try using the documentElement instead of the body
and see if the same thing happens.

I could not get documentElement to work, on that page, in IE6; so I
didn't pursue it. The leap also occurs on pressing the button.

It works adequately now in IE6, Opera 9.23, Firefox 2.0.0.7, and
probably IE 7.
If there were no universal workaround and you could be sure that an
Opera-specific workaround would not break future (or past) versions of
Opera, considering that Opera has an object to detect (as opposed to
sniffing the user agent string), then looking at window.opera wouldn't
be out of the question. The first condition is a mighty big if though
as I have never run into such a case in scripting. CSS workarounds
for IE are another story.

Too strong! One can never be quite sure what future versions might do.

But, being non-commercial, my view is that if a page of mine fails under
new circumstances, that's the user's problem until I'm told about it,
after which it's shared.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,770
Messages
2,569,583
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top