In comp.lang.javascript message <gntlgf$5r...@reader.motzarella.org>, Mon, 23 Feb 2009 00:07:51, Garrett Smith <dhtmlkitc...@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.
In comp.lang.javascript message <m2fxi424jn....@nntp.bednarz.nl>, Mon, 23 Feb 2009 23:04:44, Eric Bednarz <bedn...@fahr-zur-hoelle.org> posted:
>Dr J R Stockton <reply0...@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, Ive 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.
-- (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 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 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 wrote: > 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.
> 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.
>> 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.
> 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.
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."
kangax wrote: > 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.
>>> 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.
>> 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.
> 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 : )
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.
> From: Stevo <n...@mail.invalid> > 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>
> kangax wrote: > > 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.
> >>> 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.
> >> 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.
> > 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 : )
> 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.
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.)
> kangax wrote: > > 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.
> >>> 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.
> >> 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.
> > 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 : )
> 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
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.
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.
var el = document.createElement('div'); el.setAttribute('oncontextmenu', 'return false;'); typeof el.oncontextmenu; // "undefined"
> 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.
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
