FAQ "How do I disable the right mouse button?"
Garrett Smith
| The oncontextmenu is a proprietary method and is not supported on
| all browsers. <body oncontextmenu="return false">
It was a trend about four years ago to disable the context menu. It
seems to have fallen out of trend. That fact cannot be attributed to the
FAQ Entry.
The answer given (use "oncontextmenu") did not influence the trend away
from attempting to disable the context menu. I think this answer should
be removed. The question itself could be removed. It is not possible to
access the users hardware.
Thoughts?
Garrett
--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
Stevo
There's an easy way of achieving the desired goal of the images not
being saved from a right-click. Create a transparent GIF image, put it
on a DIV with a high z-index, and put that DIV over the image to be
protected. When the user tries to save via right-click, all they get to
save is a transparent GIF.
rf
So they will then look at the HTML and point their browsers directly at the
image. Or they will retrieve the image from their cache. Or ... any number
of other things.
Anything to do with protecting stuff by fiddling with right click is just
like putting a huge padlock on your front door and then leaving all the
windows open.
The Natural Philosopher
> Stevo wrote:
>> Garrett Smith wrote:
>>> How do I disable the right mouse button?
>>>> The oncontextmenu is a proprietary method and is not supported on
>>>> all browsers. <body oncontextmenu="return false">
>>> It was a trend about four years ago to disable the context menu. It
>>> seems to have fallen out of trend. That fact cannot be attributed to
>>> the FAQ Entry.
>>>
>>> The answer given (use "oncontextmenu") did not influence the trend
>>> away from attempting to disable the context menu. I think this
>>> answer should be removed. The question itself could be removed. It
>>> is not possible to access the users hardware.
>>>
>>> Thoughts?
>>>
>>> Garrett
>> There's an easy way of achieving the desired goal of the images not
>> being saved from a right-click. Create a transparent GIF image, put it
>> on a DIV with a high z-index, and put that DIV over the image to be
>> protected. When the user tries to save via right-click, all they get
>> to save is a transparent GIF.
>
> So they will then look at the HTML and point their browsers directly at the
> image. Or they will retrieve the image from their cache. Or ... any number
> of other things.
>
Actually the usual way to do this is to simply take a screen or window
shot, clean it up in photo* and there you go!
> Anything to do with protecting stuff by fiddling with right click is just
> like putting a huge padlock on your front door and then leaving all the
> windows open.
>
Pretty much, yes..
>
>
rf
Actually no, this is not the usual way to do this if the image is a jpg. You
then have a BMP (windows anyway) which you have to convert (in photo* or
whatever) to JPG and then re-compress, thus loosing quality. Given that most
images are (or should be) heavily optimised (compressed) for the web any
further loss of quality will be quite visible. Add in the time you spend
"cleaning it up" and it's not worthwhile.
Best to simply get the image directly from the server, not that I advocate
stealing other peoples images.
Stevo
You're both missing the point. I offered a solution to how to disable
provide the same effect of disabling right mouse click but not actually
having to worry about cross-browser methods. The same people that would
be defeated by a disabled right click would also be defeated by the
method I suggested.
It's pointless listing the merits of doing it.
rf
You are missing the point.
It's pointless suggesting *anything* that will stop people downloading and
saving images. The browser *must* download the image to display it, after
all.
This has been discussed so many times here and everywhere else over the
years that it becomes tedious. Your "solution" is one of the many that
simply do not work.
BTW Garrett's post only mentions disabling the right click context menu. It
was *you* that introduced the concept of "protecting" images.
Stevo
I don't think I am.
> It's pointless suggesting *anything* that will stop people downloading and
> saving images. The browser *must* download the image to display it, after
> all.
I also think it's pointless.
> This has been discussed so many times here and everywhere else over the
> years that it becomes tedious. Your "solution" is one of the many that
> simply do not work.
Sure it does in terms of not being able to right-click to save the image
(if that's what's wanted).
> BTW Garrett's post only mentions disabling the right click context menu. It
> was *you* that introduced the concept of "protecting" images.
True, I just assumed it was for image protection.
I just think that regardless of how pointless you or I think it is, if
that's what the OP wants I don't mind giving it to them.
rf
So, if the OP wants to protect his house against illegal entry you would
build a whopping big fortress gate at the end of his driveway, ignoring the
fact that his rest of his perimeter is an easily walkable lawn?
Stevo
If that's what he wants :-)
rf
No further comment required.
Stevo
If you take my smileyed response seriously then yes.
It wasn't a serious example though was it. It's a fact that the easiest
way of stealing an image from a site is via the right-click and save
method. So what's wrong with eliminating this easiest method.
I really don't understand the majority of people on this group that
believe if you can't provide a 100% rock-solid guarantee that images (or
JS code) theft prevention, then there's no point doing anything at all.
Why not? What's wrong with eliminating the easiest ways of stealing
images and code (disabling right-click and obfuscating code) ? We saw an
example of someone on here within the last two weeks who'd found a
compressed and obfuscated library and he gave up trying to use it
because he couldn't figure out how it worked. That's a success story for
the writer of that code, even if it was garbage.
Don't underestimate how simple the majority of users of web browsers
are. They are easily fooled by methods like stopping the right-click
context menu (or masking it by putting a transparent image over the
desired image as I suggested).
Stevo
> On Feb 20, 9:40 am, Stevo <n...@mail.invalid> wrote:
>
>> I really don't understand the majority of people on this group that
>> believe if you can't provide a 100% rock-solid guarantee that images (or
>> JS code) theft prevention, then there's no point doing anything at all.
>> Why not? What's wrong with eliminating the easiest ways of stealing
>> images and code (disabling right-click and obfuscating code) ? We saw an
>> example of someone on here within the last two weeks who'd found a
>> compressed and obfuscated library and he gave up trying to use it
>> because he couldn't figure out how it worked. That's a success story for
>> the writer of that code, even if it was garbage.
>>
>> Don't underestimate how simple the majority of users of web browsers
>> are. They are easily fooled by methods like stopping the right-click
>> context menu (or masking it by putting a transparent image over the
>> desired image as I suggested).
>
> isn't foolproof. Rather, it's that disabling the right click removes a
> LOT of other effective options for the user. Many people right click
> to use any number of the tools found in the context menu, both the
> defaults and those added through plugins. Saving images is but one
> small function there. Removing the capability handicaps many users to
> a degree, or at the very least reduces usability.
That makes my transparent GIF overlay an even better idea then. It just
shifts the focus of the right click from one image to another, retaining
all the other effective options.
Garrett Smith
> rf wrote:
>> Stevo wrote:
>>> rf wrote:
>>>> Stevo wrote:
>>>>> rf wrote:
>>>>>> Stevo wrote:
>>>>>>> rf wrote:
>>>>>>>> The Natural Philosopher wrote:
>>>>>>>>> rf wrote:
>>>>>>>>>> Stevo wrote:
>>>>>>>>>>> Garrett Smith wrote:
[...]
> Don't underestimate how simple the majority of users of web browsers
> are. They are easily fooled by methods like stopping the right-click
> context menu (or masking it by putting a transparent image over the
> desired image as I suggested).
Disabling the context menu does not achieve any security. One who is not
capable of "view source" and not motivated enough to STW for how to
view-source would not seem to be much of a concern.
OT: Digitally signing images and providing a legal page would probably
be taken more seriously and could be an effective deterrent.
Perhaps the question could be replaced with:
How to disable the context menu?
FAQ answers should not use invalid HTML. The answer should generally be
standard and should work in all major browsers. The FAQ should mention
major browsers that the solution does not work in. If the answer relies
on non-standard features, then it should be mentioned that that feature
is non-standard and the "more info" link should contain a link to the
implementation's documentation (MSDN, devmo, etc).
The current answer is invalid HTML, does not work in Opera, and does not
mention either. So, if the question is to be changed to:- "How to
disable the context menu?" - then the answer must also be changed.
Dr J R Stockton
Thu, 19 Feb 2009 23:15:37, Garrett Smith <dhtmlk...@gmail.com>
posted:
>The answer given (use "oncontextmenu") did not influence the trend away
>from attempting to disable the context menu. I think this answer should
>be removed. The question itself could be removed. It is not possible to
>access the users hardware.
There could be a new FAQ Note "What Used To Be In The FAQ". Entries
should be marked with the date of removal, and, very briefly, the reason
for removal.
<URL:http://www.merlyn.demon.co.uk/quotings.htm#Santayana>, supersedes
<URL:http://www.merlyn.demon.co.uk/quotings.htm#Hegel> &
<URL:http://www.merlyn.demon.co.uk/quotings.htm#JohnHall>.
--
(c) John Stockton, nr London UK. ??@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Eric Bednarz
> How do I disable the right mouse button?
[…]
> The answer given (use "oncontextmenu") did not influence the trend
> away from attempting to disable the context menu. I think this answer
> should be removed. The question itself could be removed.
It is a javascript question, and it is a (mis)feature that is still
requested, albeit less frequently.
> It is not
> possible to access the users hardware.
So make that the answer. As an online pointer, I’d prefer the FAQ of the
applicable Big 8 newsgroup over some random blog post.
Dr J R Stockton
21 Feb 2009 00:54:57, Eric Bednarz <bed...@fahr-zur-hoelle.org> posted:
The literal meaning of the question does not express the intended
meaning.
Clearly JavaScript cannot prevent depression of the physical right
button; and it should have no effect on clicks outside its own page (or,
possibly, daughter pages).
The common wish is to disable View Source for the page, and maybe also
saving of the page, and thus prevent access to the HTML or JavaScript
code. For authors who believe that true protection can be thus
obtained, there is indeed protection against access by those of similar
beliefs. The class expert may only wish to reduce access by his class
inferiors.
The question should be (in the current style) "How do I stop others
viewing the source of my page?", and the answer should be along the
lines of "By not making putting your page on the Web (or intranet). A
page which is viewable by a browser can be downloaded by other means; a
page which has recently been viewed can be found on the viewer's hard
disc (etc.). Suppressing the context menu normally shown by right click
provides no real protection, and prevents other use of that menu; but it
can be done, in some browsers, by ...".
Note that if the menu can be suppressed then it is useful to say
something about doing it, because a user may come across a page with
menu suppressed, and want to know about it.
In general, it is not only the answers in the FAQ which should be
reviewed, but also the questions.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Garrett Smith
> In comp.lang.javascript message <m2tz6of...@nntp.bednarz.nl>, Sat,
> 21 Feb 2009 00:54:57, Eric Bednarz <bed...@fahr-zur-hoelle.org> posted:
>> Garrett Smith <dhtmlk...@gmail.com> writes:
>>
>>> How do I disable the right mouse button?
>> […]
>>
>>> The answer given (use "oncontextmenu") did not influence the trend
>>> away from attempting to disable the context menu. I think this answer
>>> should be removed. The question itself could be removed.
>> It is a javascript question, and it is a (mis)feature that is still
>> requested, albeit less frequently.
>>
>>> It is not
>>> possible to access the users hardware.
>> So make that the answer. As an online pointer, I’d prefer the FAQ of the
>> applicable Big 8 newsgroup over some random blog post.
>
>
> The literal meaning of the question does not express the intended
> meaning.
>
I that question, as worded, could also be replied to with "Why do you
want to do that?" Which would be replied to with something that could be
answered.
Since the FAQ is not a pretend storyline/dialogue, lets just seek ahead
to the part where the question "Why do you want to do that" is answered,
reform that into a question. If that question is worth answering, then
an answer can be posted.
> Clearly JavaScript cannot prevent depression of the physical right
> button; and it should have no effect on clicks outside its own page (or,
> possibly, daughter pages).
>
The misguided attempt to prevent the user context menu as a wishful
security measure seems to have fallen out of vogue.
> The common wish is to disable View Source for the page, and maybe also
> saving of the page, and thus prevent access to the HTML or JavaScript
> code. For authors who believe that true protection can be thus
> obtained, there is indeed protection against access by those of similar
> beliefs. The class expert may only wish to reduce access by his class
> inferiors.
>
>
> The question should be (in the current style) "How do I stop others
> viewing the source of my page?", and the answer should be along the
> lines of "By not making putting your page on the Web (or intranet). A
> page which is viewable by a browser can be downloaded by other means; a
> page which has recently been viewed can be found on the viewer's hard
> disc (etc.). Suppressing the context menu normally shown by right click
> provides no real protection, and prevents other use of that menu; but it
> can be done, in some browsers, by ...".
>
I thought the question of preventing others from viewing the source was
pretty much covered by the answer to "How do I protect my javascript
code?"[1]
I think there is a different reason.
I think that preventing the context menu is the technical goal.
Motivations for that goal:
* to prevent users from stealing images
* to provide the user with a custom context menu instead
> Note that if the menu can be suppressed then it is useful to say
> something about doing it, because a user may come across a page with
> menu suppressed, and want to know about it.
>
Such as Google Maps, which suppresses the context menu in a few browsers
(but not Opera).
>
>
> In general, it is not only the answers in the FAQ which should be
> reviewed, but also the questions.
>
Exactly. What value does this question provide? Could a better question
be asked? I think "How do I prevent the context menu" would be a better
question.
Garrett
[1]http://jibbering.com/faq/#hideSource
Dr J R Stockton
21 Feb 2009 16:19:04, Garrett Smith <dhtmlk...@gmail.com> posted:
>I think that preventing the context menu is the technical goal.
>Motivations for that goal:
> * to prevent users from stealing images
> * to provide the user with a custom context menu instead
>Exactly. What value does this question provide? Could a better question
>be asked? I think "How do I prevent the context menu" would be a better
>question.
If a custom content menu can be provided, then how to do it should be
the question.
There's no especial benefit in suppressing the context menu in that
case, since one can always present an empty menu (or one with just a
divider, if empty does not work) (which at least reassures the reader
that his mouse has not broken) as a subset of presenting a new one.
And if a custom menu can be provided, perhaps the existing context menu
can have entries added - that must be of possible use, since Firefox 3
has entries on the textarea context menu which might be useful and ate
not on the corresponding IE7 menu. Chrome has yet another entry, Safari
yet another, Opera still more.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
For news:borland.*, use their server newsgroups.borland.com ; but first read
their Guidelines etc. via <URL:http://support.codegear.com/newsgroups/> ff.
RobG
[...]
> Exactly. What value does this question provide? Could a better question
> be asked? I think "How do I prevent the context menu" would be a better
> question.
Why not "How to customise the context (right click) menu", which can
also cover preventing its display and likely effectiveness (or
futility) of attempt to do so?
--
Rob
kangax
> Dr J R Stockton wrote:
[snip]
>> Note that if the menu can be suppressed then it is useful to say
>> something about doing it, because a user may come across a page with
>> menu suppressed, and want to know about it.
>>
>
> Such as Google Maps, which suppresses the context menu in a few browsers
> (but not Opera).
Opera (at least most commonly used 9.x version, as well as 10a) has
never allowed to suppress context menu. Most of the context menu
"widgets" I've seen, use Ctrl/Cmd + LeftClick to trigger custom menu in
Opera, and right click in every other browser. That's what YUI's menu
widget does, last time I checked. It also seems to be impossible to
feature test this behavior and so authors usually fall back to either UA
sniffing or object inference (e.g. presence of `window.opera` and/or its
members).
[snip]
> Exactly. What value does this question provide? Could a better question
> be asked? I think "How do I prevent the context menu" would be a better
> question.
I think so too.
--
kangax
Garrett Smith
> Garrett Smith wrote:
>> Dr J R Stockton wrote:
>
> [snip]
>
>>> Note that if the menu can be suppressed then it is useful to say
>>> something about doing it, because a user may come across a page with
>>> menu suppressed, and want to know about it.
>>>
>>
>> Such as Google Maps, which suppresses the context menu in a few
>> browsers (but not Opera).
>
> Opera (at least most commonly used 9.x version, as well as 10a) has
> never allowed to suppress context menu. Most of the context menu
> "widgets" I've seen, use Ctrl/Cmd + LeftClick to trigger custom menu in
> Opera, and right click in every other browser. That's what YUI's menu
> widget does, last time I checked. It also seems to be impossible to
> feature test this behavior and so authors usually fall back to either UA
> sniffing or object inference (e.g. presence of `window.opera` and/or its
> members).
>
An inconsistent U/X is not a good solution.
UA sniffing or object inference locks the script into behaving a certain
way for browsers that the script identifies as opera.
It is possible to detect the ability to create a contextmenu event via
DOM[1][2]. It may be possible to dispatch that event in some browsers
(though that would not be guaranteed).
Given element E:
1) Let contextMenuFired = false
2) Create a function callback that sets contextMenuFired = true.
3) Add an "oncontextmenu" callback to E with value (2).
3) Fire a contextmenu event dispatch on E
5) check the fired flag.
If the result is true, that would be a strong indication that
contextmenu events are supported.
var contextMenuFired = false;
function contextMenuCallback() { contextMenuFired = true; }
document.body.oncontextmenu = contextMenuCallback;
fireContextMenu(document.body);
document.write("contextmenu event supported: " + contextMenuFired);
Mac Results:
Safari 3, Firefox 3.0.6, SeaMonkey 1.1.14
| contextmenu event supported: true
Opera 9.5:
| contextmenu event supported: false
The whole code:-
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<title>contextmenu</title>
</head>
<body>
<script type="text/javascript">
function fireContextMenu(el){
var RIGHT_CLICK_BUTTON = 2,
doc = el.ownerDocument,
ev = doc.createEvent('MouseEvents');
if('initMouseEvent' in ev) {
ev.initMouseEvent('contextmenu', true, true, doc.defaultView, 1,
0, 0, 0, 0, false, false, false, false, RIGHT_CLICK_BUTTON, null);
}
if(typeof el.dispatchEvent != "undefined") {
el.dispatchEvent(ev);
} else if (doc.createEventObject){
el.fireEvent('oncontextmenu', ev);
}
}
var contextMenuFired = false;
function contextMenuCallback() { contextMenuFired = true; }
document.body.oncontextmenu = contextMenuCallback;
fireContextMenu(document.body);
document.write("contextmenu event supported: " + contextMenuFired);
</script>
</body>
</html>
> [snip]
>
>> Exactly. What value does this question provide? Could a better
>> question be asked? I think "How do I prevent the context menu" would
>> be a better question.
>
> I think so too.
>
It is not possible to disable a context menu in Opera. What should the
answer say?
[1]http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MouseEvent
[2]http://msdn.microsoft.com/en-us/library/ms536423(VS.85).aspx
kangax
> kangax wrote:
[snip]
>> Opera (at least most commonly used 9.x version, as well as 10a) has
>> never allowed to suppress context menu. Most of the context menu
>> "widgets" I've seen, use Ctrl/Cmd + LeftClick to trigger custom menu
>> in Opera, and right click in every other browser. That's what YUI's
>> menu widget does, last time I checked. It also seems to be impossible
>> to feature test this behavior and so authors usually fall back to
>> either UA sniffing or object inference (e.g. presence of
>> `window.opera` and/or its members).
>>
>
> An inconsistent U/X is not a good solution.
Of course.
>
> UA sniffing or object inference locks the script into behaving a certain
> way for browsers that the script identifies as opera.
See below why we can't trust `contextmenu` event.
There could be a more robust object inference. All of the Opera versions
I have (8.5 - 10a) have global `opera` property. That property is an
object with [[Class]] of "Opera". Since [[Class]] can not be set/changed
by a 3rd party script, we can somewhat safely detect Opera like so:
Object.prototype.toString.call(window.opera) == '[object Opera]';
It is of course possible for other browser to actually create the very
same global `opera` property that references an object with the very
same "Opera" [[Class]] but that seems to be unlikely.
>
> It is possible to detect the ability to create a contextmenu event via
> DOM[1][2]. It may be possible to dispatch that event in some browsers
> (though that would not be guaranteed).
>
> Given element E:
> 1) Let contextMenuFired = false
> 2) Create a function callback that sets contextMenuFired = true.
> 3) Add an "oncontextmenu" callback to E with value (2).
> 3) Fire a contextmenu event dispatch on E
> 5) check the fired flag.
>
> If the result is true, that would be a strong indication that
> contextmenu events are supported.
The problem with indication whether contextmenu events are supported is
that it has nothing to do with the way client suppresses (or not) its
native controls (such as its default context menu). Opera's native menu
simply appears every time context click occurs - no matter if event was
stopped or not.
>
> var contextMenuFired = false;
> function contextMenuCallback() { contextMenuFired = true; }
> document.body.oncontextmenu = contextMenuCallback;
> fireContextMenu(document.body);
> document.write("contextmenu event supported: " + contextMenuFired);
>
> Mac Results:
> Safari 3, Firefox 3.0.6, SeaMonkey 1.1.14
> | contextmenu event supported: true
>
> Opera 9.5:
> | contextmenu event supported: false
Some browsers produce false positives:
Safari 2.x - false
Opera 10a - true
The fact that upcoming 10a returns `true` makes such test impractical,
doesn't it?
[snip test]
>> [snip]
>>
>>> Exactly. What value does this question provide? Could a better
>>> question be asked? I think "How do I prevent the context menu" would
>>> be a better question.
>>
>> I think so too.
>>
>
> It is not possible to disable a context menu in Opera. What should the
> answer say?
What about: "While it is possible to disable a *contextmenu event* in
some versions of Opera (e.g. 10a), it is not possible to disable an
actual *context menu* in all known versions of Opera"?
>
> [1]http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MouseEvent
> [2]http://msdn.microsoft.com/en-us/library/ms536423(VS.85).aspx
>
--
kangax
Garrett Smith
> Garrett Smith wrote:
>> kangax wrote:
>
[...]
>
>>
>> UA sniffing or object inference locks the script into behaving a
>> certain way for browsers that the script identifies as opera.
>
> See below why we can't trust `contextmenu` event.
>
> There could be a more robust object inference. All of the Opera versions
> I have (8.5 - 10a) have global `opera` property. That property is an
> object with [[Class]] of "Opera". Since [[Class]] can not be set/changed
> by a 3rd party script, we can somewhat safely detect Opera like so:
>
The problem is that window.opera may likely continue to have class
"Opera", long after Opera allows preventing context menu. The two things
are unrelated.
It locks the script into behaving a certain way for browsers that
identify as opera.
[...]
>
> The problem with indication whether contextmenu events are supported is
> that it has nothing to do with the way client suppresses (or not) its
> native controls (such as its default context menu). Opera's native menu
> simply appears every time context click occurs - no matter if event was
> stopped or not.
>
I can't think of a way of detecting if calling preventDefault will
successfully prevent the context menu from appearing.
>>
>> var contextMenuFired = false;
>> function contextMenuCallback() { contextMenuFired = true; }
>> document.body.oncontextmenu = contextMenuCallback;
>> fireContextMenu(document.body);
>> document.write("contextmenu event supported: " + contextMenuFired);
>>
>> Mac Results:
>> Safari 3, Firefox 3.0.6, SeaMonkey 1.1.14
>> | contextmenu event supported: true
>>
>> Opera 9.5:
>> | contextmenu event supported: false
>
> Some browsers produce false positives:
>
> Safari 2.x - false
> Opera 10a - true
>
> The fact that upcoming 10a returns `true` makes such test impractical,
> doesn't it?
>
No. That is an alpha browser.
I think it would be wise to wait at least until 10.0 is released before
drawing such conclusions.
Just curious, what does Opera 10a result with:-
javascript:alert('oncontextmenu' in document.body);
Garrett
Eric Bednarz
>>> How do I disable the right mouse button?
> The literal meaning of the question does not express the intended
> meaning.
IMO a question in a FAQ should relate to the audience that is likely to
bring the matter up, not the audience that is likely to answer it.
> The question should be (in the current style) "How do I stop others
> viewing the source of my page?", […]
Now *you* are just making assumptions. In a more or less serious
business environment, I’ve never encountered a customer who wanted to
prevent that, but quite a couple who wanted to ‘protect’ images (with
occasionally even sensible motivation); none of them considered that
crippling the user interface, by the way, because they never knew it was
one. None of them would see a relation between protecting source code
and protecting images either. YMMD, etc.
Dr J R Stockton
Mon, 23 Feb 2009 00:07:51, Garrett Smith <dhtmlk...@gmail.com>
posted:
>
>It is not possible to disable a context menu in Opera. What should the
>answer say?
>
That the context menu can be disabled in some, but not all, browsers.
That disabling the context menu does not prevent source access by other
means, and does disable other right-click convenience features.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Dr J R Stockton
23 Feb 2009 23:04:44, Eric Bednarz <bed...@fahr-zur-hoelle.org> posted:
>Dr J R Stockton <repl...@merlyn.demon.co.uk> writes:
>
>>>> How do I disable the right mouse button?
>
>> The literal meaning of the question does not express the intended
>> meaning.
>
>IMO a question in a FAQ should relate to the audience that is likely to
>bring the matter up, not the audience that is likely to answer it.
No; it should relate to both.
"How do I disable the right mouse button menu of my page?" will serve
better.
>> The question should be (in the current style) "How do I stop others
>> viewing the source of my page?", […]
>
>Now *you* are just making assumptions. In a more or less serious
>business environment, I’ve never encountered a customer who wanted to
>prevent that, but quite a couple who wanted to ‘protect’ images (with
>occasionally even sensible motivation); none of them considered that
>crippling the user interface, by the way, because they never knew it was
>one. None of them would see a relation between protecting source code
>and protecting images either. YMMD, etc.
Images are part of the source of a displayed page, except in a strict
technical sense.
There are environments other than "more or less serious business", and
the FAQ should cover those too.
Those who want to "disable the right button" for purposes of protection
will find a "general protection" title to be appropriate.
kangax
> kangax wrote:
[...]
>> versions I have (8.5 - 10a) have global `opera` property. That
>> property is an object with [[Class]] of "Opera". Since [[Class]] can
>> not be set/changed by a 3rd party script, we can somewhat safely
>> detect Opera like so:
>>
>
> The problem is that window.opera may likely continue to have class
> "Opera", long after Opera allows preventing context menu. The two things
> are unrelated.
True.
>
> It locks the script into behaving a certain way for browsers that
> identify as opera.
I understand that feature detecting this behavior is the sanest way to
go, but there doesn't seem to be a reliable feature test in the first
place. This means that we either abandon the idea of detecting this
behavior or resort to some kind of inference strategy. One possibility
is to check for presence of global `opera` (or rather its [[Class]]),
and perhaps, `opera.version` as a vendor-provided way of detecting a
browser version (contrary to unreliable - both, in theory and in
practice - UA string).
This is obviously unreliable. There's no guarantee that another client
won't have a global `opera` property referencing object with "Opera"
[[Class]] with a certain `version` property.
This seemingly insane inference is backed by practical observation
(the same observation that is the reasoning behind `isHostMethod`
assuming object's host method nature based on a `typeof` returning
"unknown" in MSHTML DOM) and practical observations could work somewhat
well : )
>
> [...]
>
>>
>> The problem with indication whether contextmenu events are supported
>> is that it has nothing to do with the way client suppresses (or not)
>> its native controls (such as its default context menu). Opera's native
>> menu simply appears every time context click occurs - no matter if
>> event was stopped or not.
>>
>
> I can't think of a way of detecting if calling preventDefault will
> successfully prevent the context menu from appearing.
Me neither.
[...]
> No. That is an alpha browser.
>
> I think it would be wise to wait at least until 10.0 is released before
> drawing such conclusions.
Ok.
>
> Just curious, what does Opera 10a result with:-
> javascript:alert('oncontextmenu' in document.body);
'oncontextmenu' in document.body; // false
typeof document.body.oncontextmenu; // "undefined"
Opera 10a doesn't seem to produce any kind of event when context click
occurs - mousedown, mouseup, click - none of those are fired. It's as if
DOM is not aware of this action at all. I also noticed that context
click on a <BUTTON> element never brings up the menu, but that's hardly
helpful.
--
kangax
Garrett Smith
> Garrett Smith wrote:
>> kangax wrote:
> [...]
>>> There could be a more robust object inference. All of the Opera
>>> versions I have (8.5 - 10a) have global `opera` property. That
>>> property is an object with [[Class]] of "Opera". Since [[Class]] can
>>> not be set/changed by a 3rd party script, we can somewhat safely
>>> detect Opera like so:
>>>
>>
>> The problem is that window.opera may likely continue to have class
>> "Opera", long after Opera allows preventing context menu. The two
>> things are unrelated.
>
> True.
>
>>
>> It locks the script into behaving a certain way for browsers that
>> identify as opera.
>
> I understand that feature detecting this behavior is the sanest way to
> go, but there doesn't seem to be a reliable feature test in the first
Keep working on it.
javascript:alert('oncontextmenu' in document)
True in Safari 2.
But that doesn't work in Firefox. So we can use the other strategy for that.
However, there is no "fallback" for what to do if context menu is not
supported. If no fallback can be provided, then it is pointless. It
would be more efficent and equally effective to add the oncontextmenu
callback and hope it works. However, realizing that, it might be a
better idea to consider another strategy that is more widely supported
and allows the user to effectively accomplish the same goals.
> place. This means that we either abandon the idea of detecting this
> behavior or resort to some kind of inference strategy. One possibility
> is to check for presence of global `opera` (or rather its [[Class]]),
> and perhaps, `opera.version` as a vendor-provided way of detecting a
> browser version (contrary to unreliable - both, in theory and in
> practice - UA string).
>
The false positive of Opera is indication that they might be working on it.
If you exclude Opera, or I should instead say, if you exclude an
implementation where window.opera has a class property of "Opera". If
you do that, then it means opera implementing contextmenu events will
still get excluded from running perfectly good code.
It would be like saying:-
if(document.all) {
alert('cannot use getElementById');
} else if(document.getElementById) {
alert('getElementById works');
}
as -
var isOpera = ({}).toString.call(window.opera) == "[object Opera]";
if(isOpera) {
alert('cannot use contextmenu');
} else if(canCreateContextMenu) {
alert('contextmenu events work');
}
Because in both cases, we have the first condition is true, and the
second condition, we know does not work as of the latest version of that
browser. IE 4 did not support document.getElementById, and so a program
could use that code and produce a desirable result at that point in time.
However, later, IE implemented getElementById while more browsers
continued to implement document.all.
The only problem will be is if Opera leaves the implementation as it is;
that is, contextmenu can be created by createEvent, but is not
implemented, never fires, and thus cannot be prevented.
On a side note it would be useful if more browsers would allow detecting
event handler support with:-
eventName in obj;
Where eventName is something like "oncontextmenu".
> This is obviously unreliable. There's no guarantee that another client
> won't have a global `opera` property referencing object with "Opera"
> [[Class]] with a certain `version` property.
>
Why would any browser do that? Why would a browser try to identify as
Opera, in a way that is not normally used to detect Opera? The
motivation to identify as opera seems almost as unlikely as the proposed
means by doing so (faking window.opera down to the [[Class]] property).
> This seemingly insane inference is backed by practical observation
> (the same observation that is the reasoning behind `isHostMethod`
> assuming object's host method nature based on a `typeof` returning
> "unknown" in MSHTML DOM) and practical observations could work somewhat
> well : )
>
Another browser engine could create host objects where typeof hostobj ==
"unknown" would be true.
>
> Opera 10a doesn't seem to produce any kind of event when context click
> occurs - mousedown, mouseup, click - none of those are fired. It's as if
> DOM is not aware of this action at all. I also noticed that context
> click on a <BUTTON> element never brings up the menu, but that's hardly
> helpful.
>
>
Wait until they're done with it.
I have good feeling contextmenu events make it into Opera 10.x. In fact,
I will bet money on that.
kangax
[...]
> However, there is no "fallback" for what to do if context menu is not
> supported. If no fallback can be provided, then it is pointless. It
> would be more efficent and equally effective to add the oncontextmenu
> callback and hope it works. However, realizing that, it might be a
> better idea to consider another strategy that is more widely supported
> and allows the user to effectively accomplish the same goals.
The most widely used fallback is using Ctrl/Cmd + Click. While it's
inconsistent, it seems to be a de-facto standard and can be expected to
be known by users. Yahoo Mail with its 260 million uses (as per
wikipedia) uses it, so do most of other contextmenu scripts on the web.
That is exactly why I mentioned `opera.version`. We can account for only
Opera <10 since those are the versions which we *know* don't work.
Checking only for `opera` is clearly not future-friendly : )
>
> The only problem will be is if Opera leaves the implementation as it is;
> that is, contextmenu can be created by createEvent, but is not
> implemented, never fires, and thus cannot be prevented.
>
> On a side note it would be useful if more browsers would allow detecting
> event handler support with:-
>
> eventName in obj;
>
> Where eventName is something like "oncontextmenu".
Absolutely. Detecting events support is painful.
>
>> This is obviously unreliable. There's no guarantee that another client
>> won't have a global `opera` property referencing object with "Opera"
>> [[Class]] with a certain `version` property.
>>
>
> Why would any browser do that? Why would a browser try to identify as
> Opera, in a way that is not normally used to detect Opera? The
> motivation to identify as opera seems almost as unlikely as the proposed
> means by doing so (faking window.opera down to the [[Class]] property).
Of course it is unlikely. I haven't seen such browser and most likely
never will. The point is that this is unreliable, but the chances of
such unreliability are pretty low.
>
>> This seemingly insane inference is backed by practical observation
>> (the same observation that is the reasoning behind `isHostMethod`
>> assuming object's host method nature based on a `typeof` returning
>> "unknown" in MSHTML DOM) and practical observations could work
>> somewhat well : )
>>
>
> Another browser engine could create host objects where typeof hostobj ==
> "unknown" would be true.
Yes. Browser could also throw errors when those "unknown" objects are
called. Yet, `isHostMethod` assumes that typeof "unknown" is safe to
call. We can't safeguard ourselves from such changes.
>
>>
>> Opera 10a doesn't seem to produce any kind of event when context click
>> occurs - mousedown, mouseup, click - none of those are fired. It's as
>> if DOM is not aware of this action at all. I also noticed that context
>> click on a <BUTTON> element never brings up the menu, but that's
>> hardly helpful.
>>
>>
>
> Wait until they're done with it.
>
> I have good feeling contextmenu events make it into Opera 10.x. In fact,
> I will bet money on that.
I have just asked Hallvord (Opera Software Core JavaScript tester) to
clear things up. He said this -
"...support for the oncontextmenu event is long overdue - and we are
working on it. Still somewhat uncertain if it gets into 10.00 because we
would first have to fix the bug that makes Opera pop up its native menu
even if the script calls preventDefault(). This appears to be a tricky
fix so at this point we'll have to wish the developers best of luck with
that and cross our fingers..."
"...Some version of Opera will support oncontextmenu and let you
suppress the native menu (Unless the user disables JS and/or "Allow
JavaScript to detect right click" preferences. Whether that version is
10 or the one after I'm not sure yet."
Start betting your money! ; )
--
kangax
Garrett Smith
> Garrett Smith wrote:
> [...]
>> However, there is no "fallback" for what to do if context menu is not
>> supported. If no fallback can be provided, then it is pointless. It
>> would be more efficent and equally effective to add the oncontextmenu
>> callback and hope it works. However, realizing that, it might be a
>> better idea to consider another strategy that is more widely supported
>> and allows the user to effectively accomplish the same goals.
>
> The most widely used fallback is using Ctrl/Cmd + Click. While it's
> inconsistent, it seems to be a de-facto standard and can be expected to
> be known by users. Yahoo Mail with its 260 million uses (as per
> wikipedia) uses it, so do most of other contextmenu scripts on the web.
>
Google Maps uses that approach, too.
Excluding for Opera < 10 excludes other browsers that support context menu.
The way to detect support so far seems to be
1) check 'oncontextmenu' in document
2) if true, contextmenu event is supported. return.
3) programmatically create a contextmenu event, add a contextmenu
callback to an element, and dispatch the event on that element.
>>
>>>
>>> Opera 10a doesn't seem to produce any kind of event when context
>>> click occurs - mousedown, mouseup, click - none of those are fired.
>>> It's as if DOM is not aware of this action at all. I also noticed
>>> that context click on a <BUTTON> element never brings up the menu,
>>> but that's hardly helpful.
>>>
>>>
>>
>> Wait until they're done with it.
>>
>> I have good feeling contextmenu events make it into Opera 10.x. In
>> fact, I will bet money on that.
>
> I have just asked Hallvord (Opera Software Core JavaScript tester) to
> clear things up. He said this -
>
That is a pretty reliable source. You probably should have asked him
before you posted that, however.
Robert Maas, http://tinyurl.com/uh3t
> There's an easy way of achieving the desired goal of the images not
> being saved from a right-click. Create a transparent GIF image, put it
> on a DIV with a high z-index, and put that DIV over the image to be
> protected. When the user tries to save via right-click, all they get to
> save is a transparent GIF.
How is the user stopped from using this procedure to download the
image anyway:
- Press print-screen button on keyboard.
- Start up MS-Word, and press control-V to paste the screen-image
graphic into the MS-Word document.
- SaveAs WebPage. This creates a sub-directory containing two
versions of each graphics element, a high-resolution PNG, and a
low-resolution JPEG.
- Start up Paint, load the high-resolution PNG image, crop just the
part you really wanted, and save to disk as JPEG.
I have found several Web sites that seem to have embedded images
but the images can't be downloaded by right-click save-image, but
the print-screen method has never failed to get the image anyway.
Is there a way that JavaScript can disable the print-screen key??
Ah, specific example: On HotOrNot, you can ask it to display your
histogram of ratings of your photo on-screen, but it's not an
image, it's a graph apparently drawn by JavaScript directly onto
the "canvas" of the WebPage DOM. But print-screen can get it!
For example, here's the rating of my photo when I was deathly sick
but needed to get my driver's license renewed and DMV insisted on
replacing my license photo at such an inopportune time, which photo
got a *better* HotOrNot rating than other photos taken of me when I
was feeling better, proving that women really are sadistic men-haters:
<http://www.geocities.com/cuddledarling7/ImagesS2/NearDeadRat.JPG>
Here's the same histogram reformatted to work on one-inch cellphone:
<http://www.geocities.com/cuddledarling7/ImagesS2/NearDeadRatVS.JPG>
David Mark
I prefer:
1) Detect setAttribute works, if not check property for null or
function (IE)
2) Set an onclick attribute on a created element
3) Check onclick property for function
Just like isHostMethod, step #1 takes a detour for IE that is based on
ten years of the most widely installed and used browser software out
there. I'm hoping that at least one mode of IE8 will fix setAttribute
and maybe in five years the old IE5-7 branch can be removed.
I doubt they'll change the "unknown" type for IE8, but anything's
possible. That's why it is good to encapsulate such testing in a
method. If IE adds "mickeymouse" or whatever as a new type and it is
determined to be another alias for an ActiveX property, then that will
have to be added to the regex. As for other browsers copying
"unknown" types, the best candidate for that would be Opera. Doubtful
they would break compatibility with IE's "unknowns' (assuming they can
account for all of them!) Does not imply a callable method either.
That's why isHostMethod is only for properties that are expected to be
methods if present. For example, using isHostMethod (as opposed to a
similar variation for objects) to detect offsetParent would be a
mistake and could produce a false positive.
The browser developers seem to understand that typeof is the operator
of choice for testing properties of host objects. They have yet to
foul anything up along those lines that I know of. However, the - in
- operator doesn't tell anything about a property, except that it
exists (i.e. it could be null, false, etc.)
[snip]
David Mark
Forgot to mention, I thought I had tried this before and discarded the
idea. This is why:
window.alert('onclick' in document)
It's false in FF3 (and others I suspect.) Of course, it would be true
if another script set it. I think it comes back to a created element,
setAttribute and the typeof operator.
[snip]
kangax
>> The way to detect support so far seems to be
>> 1) check 'oncontextmenu' in document
>> 2) if true, contextmenu event is supported. return.
>> 3) programmatically create a contextmenu event, add a contextmenu
>> callback to an element, and dispatch the event on that element.
>
> I prefer:
>
> 1) Detect setAttribute works, if not check property for null or
> function (IE)
> 2) Set an onclick attribute on a created element
> 3) Check onclick property for function
Just checked in Opera (8.54, 9.27, 9.5, 9.64 and 10a; on OSX 10.5.6) and
the results are all consistent.
var el = document.createElement('div');
el.setAttribute('oncontextmenu', 'return false;');
typeof el.oncontextmenu; // "undefined"
[...]
--
kangax
David Mark
> David Mark wrote:
> > On Feb 25, 2:44 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> [...]
> >> The way to detect support so far seems to be
> >> 1) check 'oncontextmenu' in document
> >> 2) if true, contextmenu event is supported. return.
> >> 3) programmatically create a contextmenu event, add a contextmenu
> >> callback to an element, and dispatch the event on that element.
>
> > I prefer:
>
> > 1) Detect setAttribute works, if not check property for null or
> > function (IE)
> > 2) Set an onclick attribute on a created element
> > 3) Check onclick property for function
>
> Just checked in Opera (8.54, 9.27, 9.5, 9.64 and 10a; on OSX 10.5.6) and
> the results are all consistent.
That's what I would expect from a DOM that does not support the
contextmenu event. When and if Opera adds support for this feature,
the code will follow without modification.
>
> var el = document.createElement('div');
> el.setAttribute('oncontextmenu', 'return false;');
> typeof el.oncontextmenu; // "undefined"
Don't forget to make sure that setAttribute works. I do this by
testing getAttribute as IE always breaks those as a set. Some day MS
will release a browser with a working attributes, but IE6/7 are going
to be around for years after.
kangax
>> var el = document.createElement('div');
>> el.setAttribute('oncontextmenu', 'return false;');
>> typeof el.oncontextmenu; // "undefined"
>
> Don't forget to make sure that setAttribute works. I do this by
> testing getAttribute as IE always breaks those as a set. Some day MS
I see this test in your "My Library":
...
attributesBad = !!(html && isHostMethod(html, 'getAttribute') &&
html.getAttribute('style') && typeof html.getAttribute('style') ==
'object');
...
Is this what you meant?
> will release a browser with a working attributes, but IE6/7 are going
> to be around for years after.
IE8 fixed most of the (get|set)Attribute bugs, AFAIK.
--
kangax
David Mark
> David Mark wrote:
> > On Mar 16, 2:05 pm, kangax <kan...@gmail.com> wrote:
> [...]
> >> var el = document.createElement('div');
> >> el.setAttribute('oncontextmenu', 'return false;');
> >> typeof el.oncontextmenu; // "undefined"
>
> > Don't forget to make sure that setAttribute works. I do this by
> > testing getAttribute as IE always breaks those as a set. Some day MS
>
> I see this test in your "My Library":
>
> ...
> attributesBad = !!(html && isHostMethod(html, 'getAttribute') &&
> html.getAttribute('style') && typeof html.getAttribute('style') ==
> 'object');
> ...
>
> Is this what you meant?
More or less. As with much of the code in the library, there is room
for improvement. I think the last test should be != 'string'.
>
> > will release a browser with a working attributes, but IE6/7 are going
> > to be around for years after.
>
> IE8 fixed most of the (get|set)Attribute bugs, AFAIK.
I doubt it is fixed in the legacy modes.