Closed Bug 86193 (oncontextmenu) Opened 23 years ago Closed 20 years ago

Prevent websites from disabling the mouse right-click context menu - disallow sites access to Window.oncontextmenu and friends

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.7beta

People

(Reporter: BenB, Assigned: caillon)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: access, helpwanted, regression, Whiteboard: See comment 149 for instructions on how to use this option | [p-ie/mac])

Attachments

(2 files, 3 obsolete files)

Patch for reviews
5.60 KB, patch
jst
: review+
bryner
: superreview+
Details | Diff | Splinter Review
testcase
876 bytes, text/html
Details 
Counter-bug to bug 72084.

The option to disallow websites (remote content in general) to interfere with
the browser's context menu in any way.

Bug 71705 is related, but not a dup.
Blocks: 86195
No longer blocks: 86195
Keywords: mozilla1.0, regression
Blocks: 86195
See also bug 40535, [RFE] disallow/queue alert (and window.open?) on right-
click.
Whiteboard: [p-ie/mac]
Target Milestone: --- → mozilla1.0
Keywords: helpwanted
IMO this bug should be resolved as invalid.  

<ironic>hyatt, right, after all, the web page is what should control Mozilla,
not the user. All power to AOL, Microsoft and doubleclick.net!</ironic>

Adding some of the "discussion" Jesse promised:

<quote src="bug 28604" author="me">
IMO, it is none of the business of a webpage to mess with context menus in any
way. Sometimes (e.g. after a window.open or when I minimize the normal chorme),
the context menu is my only way to interact with the app. E.g. to access "View
Source" or to specify how to open a link or anything. A webpage must not be
allowed to interfere with my ability to do so. [I would argue that everything
else is close to a denial of service.]

I have seen pages that tried to prevent me from looking at the source. This must
not happen.

In this case, a don't care about any W3C spec. This is basic usability. At the
very least, I must have the option (with UI) to disallow such malicious
behaviour of webpages. Everything else is IMO a serious bug.
</quote>

Compare mstoltz in bug 92955: "Sure it's privacy-related. Pop-up ads are a
violation of my privacy (in that they are annoying, not that they steal personal
info)." (But I don't add |privacy| keyword here.)

More discussion: <news://news.mozilla.org/3ACDE0A2.6090209@beonex.com>.
Hyatt, I think this is a legitimate concern. Please don't mark it wontfix. I may
be able to do this with per-event security policies (bug 64737, seems to be the
hot issue of the day).

Ben, I agree with you that the user should have full control over how, or even
if, certain types of content are displayed or scripts run. However, as Shaver
pointed out to me, 'privacy' has come to refer to the protection of a user's
personal information. So, we need a different term for this. 'Content control'
is sufficiently general, though unfortunately it sounds like censorship, which
is of course not the idea at all.
Depends on: 64737
No longer depends on: 64737
SPAM - sorry.
Depends on: 64737
I'm marking this [Aufbau-P5] for now, but the first time a porn site tries to
stop me from saving an image, I'm upgrading this bug.
Whiteboard: [p-ie/mac] → [Aufbau-P5] [p-ie/mac]
> [Aufbau-P5]

I asked Neils and he told me that this is for bug 107162.
Whiteboard: [Aufbau-P5] [p-ie/mac] → [p-ie/mac]
I hope, this is the right place. An option to disable
right-mouse-button-disabeling with JavaScript would fit very well to the Scripts
section in the Advanced Preferences. As it stands right now you need to use
WebWasher (or something similar) to achive this.

pi
Content stealing is the upcoming hot issiue. There is a growing angry community
out there concerned about having their content stolen and displayed as if it was
somebodyelse's creation. This has nothing to do with privacy or security. If the
page denies you from seeing the source, dont visit that page again. It is that
simple. Also, having contextmenu always active will be also messing up the
entire idea of XUL. Disable the cookies if you are concerned, you are all set
for the good of your privacy; the rest of your concerns are more like specific
to your own megalo-browser dream.The ambition of having the full control of the
web browser is unfortunately extra-terrestrial. On the other hand, You may
create a mozilla version of yours which would do that 'having contextmenu open
all the' thing if you wish. That is doable, right? Or there could be a compile
time macro which will activate or deactivate the feature you want.

with amusement,(Sorry)
Yes, I am that old-fashioned to think that *my* devices should do what *I* want.

There is no option to disable this behaviour, which is exactly the subject of
this bug.

The "stolen content" argument is spurious. People who want to "steal your
content" can just use wget.

> If the page denies you from seeing the source, dont visit that page again.
> It is that simple.

"If you want to prevent your content being stolen, don't put it on the public
internet. It is that simple."

I agree with Ben and am feeling righteous enough today to feel that I speak for
the majority. Disabling context menus does not protect source; it limits access
to browser features (like load image, open link in new window, back, bookmark,
send page etc). If you want to protect your source, shut off your web server...
lest I telnet to port 80 and fetch it myself (not that I want it).

-matt
First, you should speak for yourself. I am not that naive to accept populist 
argumants like "I speak for majority". Second, I am not concerned about closing 
or protecting my source. I was refering to people who is angry about it. 

Third, Are you telling me that one should not put his/her content over the 
internet because couple of people wants so? Well, in that case, I want to put 
[right now], for example, my page over the internet and do not want that damn 
contextmenu over my content, go use the menubar. Do you have any right to stop 
me doing this? NO! if you dont like my page, dont use my port 80 again. It is 
my port 80 and the content flowing thru my 80 wants no contextmenu. I dont give 
a damn about which browser is connected, just my content doesnt want to have 
contextMenu. Does this breach your security or privacy? Hell No!

Last but not least, Hmm, lets see, telnet to port 80 and petch the page hmm?. 
But I am thinking about using HTTPS and closing the port 80. What do you say 
Einstein? will you dig the browser cache now? Now please dont go any further 
and dont try to point me to some third party openSSL HTTP clients. If you are 
that sophisticated, contextMenu disabling shouldnt bother you at all.

end of my involvement with this wanna be BUG. Rest is none of my concern.
would you guys please cut it out, go to a newsgroup, or die?

if people want to protect their work from source sniffing, they should use 
shockwave or an equivalent.
timeless, you are perfectly right. I am sorry If I offended anybody; It was 
definitely not my intend. Well, good luck.
Target Milestone: mozilla1.0 → mozilla1.1
Here's an idea... Provide a meta key for the right-click that will always open
the standard "default" context menu, regardless of what the page does. Example:
If you just right-click, you will get the context menu or whatever the page
redefined it to be. If you alt-right-click, you will ALWAYS get the default
mozilla context menu.

This would satisfy both sides; if a page wants to add to the menu, they can...
If the page deletes useful commands from the context menu, the user can can
still get to them with an alt+right-click (or whatever meta-key is selected),
and since the user has to go through extra effort, they cannot complain if some
web application breaks as a result.

-John
That's a great idea. It could be done for middle click too (open in new tab).

It would also be useful for left click (left-drag, to select text -- I've never
found anyone so dumb as to try to prevent copying text, but I bet they exist).

I vote for alt too.
alt-click/alt-right-click/alt-middle-click are commonly-used windowmanager
shortcut on Unix.  This means programs never get those events.  Please do not
make any accessibility-critical feature use those combinations.
How about shift then?
*** Bug 132272 has been marked as a duplicate of this bug. ***
This looks like a dup of bug 70135
Depends on: 70135
This issue stems from the original Mozilla bug (#72084 of 3/15/2001) which I 
submitted.  The purpose of this ability to disable the context menu (in my 
case) has absolutely nothing to do with preventing the ability to "view 
source".  This can be had via the menu bar ANYWAY.  The purpose of this is to 
prevent the user from selecting the manner in which my application (I repeat, 
my application) is launched.  With the movement well underway to make true web-
based applications, the application developer needs to control the manner in 
which the application is launched and used.  With a simple web page, this is 
not an issue, but with a true web-based application, its a fact that cannot be 
ignored.  

The original purpose is clearly stated in the opening remarks of that bug.  
I've included it below for reference purposes:

"Currently, is there any way to completely disable the right-click context menu 
in the Mozilla browser? For Mozilla to be a valuable business application 
platform, application developers need a JavaScript event handler exposed to 
disable the display of the context menu.  This would prevent users from 
inadvertantly opening the current application in a new browser window....which 
could have serious side-effects in a stateful application model."




It comes down to whether the web browser exists to deliver applications or
content.  In the former case, disabling context menus may be understandable.  In
the latter it is completely unacceptable.

Unfortunately, people keep trying to coerce HTML to do both, so there is no way
to tell which we're dealing with....
bcortez,

we discussed this before on the newsgroup almost exactly one year ago, and I
replied to most of your recent statements back then already. See the link in
comment 3 and the following thread.

> has absolutely nothing to do with preventing the ability to "view 
> source".  This can be had via the menu bar ANYWAY.

There is no menu, if the site disabled it.
*** Bug 138775 has been marked as a duplicate of this bug. ***
I browse using context menu 95% of the time, so there...
*** Bug 150940 has been marked as a duplicate of this bug. ***
by disabling the context menu,
websites also prevent me from banning their ad gifs
*** Bug 151362 has been marked as a duplicate of this bug. ***
Couldn't shift be used as suggested in comment 18 ?
That's it: if the user press shift and right-click (or the windows' context menu
key), then either no event is sent to the page, or the event is turned into a
non-cancelable event.

I respect comment 21 as I'm also a web developer and I use the oncontextmenu
event to provide a modifed menu under certain conditions (that's it not all the
page has blocked the event, only a section that allows me to avoid clutter by
providing the options only when needed), but as a user I hate when a page
removes the context menu completely.

Allowing to use a modifier as Shift it would mean that there's no need for
another preference, anyone could surf normaly and if some page is bad designed
only by pressing one key we get back the context menu. If the user is in a web
application and he uses the trick to use the context menu and then the
application 'breaks' then the user is the one to blame because he has used
something that the author didn't want to and it's not the same situation like
having a preference disabled for all sites and then when he is using the web
application he doesn't know that the author specified a special handler for the
oncontextmenu.

does anyone find any problem to use the modifier key approach instead of a
preference?
Yes, it is not discoverable for normal users and I should not have to take
special action to resume normal operation of my browser. I want to set a hidden
pref (by default) in Beonex Communicator and forget about this crap.
Is ctrl+PageUp, Ctrl+PageDown discoverable for normal users?
Shift+click on links?

A shorcut is discoverable if it's documented.
> Is ctrl+PageUp, Ctrl+PageDown discoverable for normal users?
> Shift+click on links?

No, none of them are discoverable.

Sorry for my last comment. But I want a preference which I can set and be sure
that a site will never be able to interfere with the context menu (esp. not
remove options). Other options to circumvent bad sites are fine with me.
> > has absolutely nothing to do with preventing the ability to "view 
> > source".  This can be had via the menu bar ANYWAY.

> There is no menu, if the site disabled it.

There is always Ctrl-U.  I don't think there's any way a site can disable that.
Sure it can.  Just coopt the "ctrl-u" shortcut and preventDefault() or
preventBubble() the keyboard event.
Can oncontextmenu="return false" be disabled with security policies as described
in http://www.mozilla.org/projects/security/components/ConfigPolicy.html ?  I've
tried permutations of: 

user_pref("capability.policy.default.document.oncontextmenu", "noAccess"); 

but haven't been successful.  The examples at the ConfigPolicies URL all deal
with access to properties, while oncontextmenu is an event. So there are no
templates there on which to work from.
Target Milestone is in the past.

pi
The default operation should definately be not to let sites do ANYTHING with the
right click. I think this operation belongs to kiosk mode and because Mozilla
doesn't have such mode (yet), bug 72084 is invalid.

Anyway, I'll be happy if this appears as a checkbox on preferences, but the
default should be not allowing websites touch it. Making users shift-click or
something is just not good design for content viewer.

Web designers shouldn't use right mouse button for anything vital anyway - many
people don't even have such button or need to access its function by longer road.

I'll never understand, why this ideotic event handler got added. It's not a W3C
Standard, it's not required to get any page usable or looing better, it's only
to let some kiddies think they are cool, if they block your right mousebutton
and replace this by sometihnk, which should make this a security related bug,
like a window.open() or even nicer - self.close().
It is not possible to perpit content any layout stealing and this doesn't even
make it more difficult (or do you think those people are to stipid to disable
JavaScript?), it just and simply makes realy _every_ page a risk, as you'll
never know, what's hidden on the right mousebutton.
Blocks: Beonex
I think Bug 167396 has the same roots. (Disables selecting text by mouse besides
context menu)
Its URL has a very annoying example.
I think this bug should be more general. Right now it only focuses on context
menu, while bug 167396 focuses on text selection. Why not making this bug a
general bug to not allow pages to prevent ANY mouse button function from
working? After all the solution to the problem is the same for both mouse
buttons, isn't it? While these might be two different preference settings, I
still think it's basically the same bug (it should also cover capturing of
middle mouse button if this is possible in JavaScript).
Blocks: useragent
No longer blocks: 86195
Alias: oncontextmenu
Severity: normal → major
*** Bug 169650 has been marked as a duplicate of this bug. ***
Let me jump in here. One of the powerful things about the Mozilla preferences is
the "allow scripts to" functions.  It is great that I can configure what
mischief I want to disallow web developers from using on me.   

I just ran across a tag: 
<oncontextmenu='return false'>
where the web developer has disabled the context menu.  This basically nulled
the right clicks, preventing me from viewing page source, or even opening a link
in a new tab or window.  

Mozilla has long not supported reassigning of the mouse buttons, and that's
good.   There should be an item in the "allow scripts to" for "allow/disallow
mouse button tampering".  

I realize this suggestion expands the scope of this bug, but it also perhaps 
makes it easier to deal with.  I notice it is languishing and has not been
worked on.
Attached patch Concept patch (obsolete) — — Splinter Review 
This should do the trick.  The pref name is up for debate, and whether or not
we want a UI is up for debate too.  Whether or not this will even be taken is
up for debate since this is a conscious decision to enable this feature for IE
compat.  Nonetheless, here is the general work needed to make this happen.

BenB said he was going to adopt this and attempt to get it into Mozilla, if
possible, and if not, then at least into Beonex.
Two questions:

1)  Should we silently ignore the call, or should we generate an exception? (I
    lean towards the former, I guess)
2)  If the latter, could we do this in the script security manager and for all
    events, a la the existing capability policies?
Re comment #44 1: Bug 117707 fixed that disabling status bar JS changes would
not throw an exception.  The logic (and part of the patch?) used there could
perhaps be applied to here.  The blocked oncontextmenu call should show up as a
message on the JS console.

Re comment #44 2: Extending the fix from this bug to other events (onhover,
onfocus, etc) would fix Bug 150872.

Not really.  It would give an on-off switch, which is not nearly as flexible as
the security policy mechanism.  Unfortunately, this last just throws exceptions...
Boris, I asked jst about exceptions last night before submitting the patch.  No
exceptions should be thrown from addEventListener.  So we should silently ignore
it as I've done.
*** Bug 173800 has been marked as a duplicate of this bug. ***
"BenB said he was going to adopt this and attempt to get it into Mozilla, if
possible, and if not, then at least into Beonex."

Funny how this super-ego thing really works. Why dont you guys keep this in 
Beonex and leave Mozilla alone? I think it is an excellent idea to keep this in 
Beonex only. You dont want contextmenu disabling deal, go use Beonex. I support 
this 100%.
*** Bug 174792 has been marked as a duplicate of this bug. ***
> Why dont you guys keep this in Beonex

Because I do not use Beonex and have no plans to use Beonex.  I _do_ however
want to control _my_ browser (notice that it's _mine_, not _yours_).
Why is it that the idiot web dee-zine-ers who put in those truly retarded
scripts to attempt to disable features in users' browsers aren't being
egotistical (along with being imbeciles), but those of us who want our browser
of choice to provide the ability to ignore these attempts are showing "super-ego"?
I dont know! why dont you ask them? their egoistic page does not bother me 
because I wont visit their page again if it really bothers me; however, 
everybody should be given the freedom to do whatever they wanna do with their 
content. The freedom must not work one way. Site designers should be given 
freedom to disable interfaces given over their content. If that bothers you, 
you are free not to visit their site again. If they dont want you to select 
text or download picture, they have a freedom to do so, and you have a freedom 
to not to visit that site again. Although the browser is your browser, content 
displayed is not. Context menu opened over the content should be considered as 
part of the content and content owner should be given freedom to disable it(a 
custom menu can be used by content for right click for example). Mozilla has 
advanced features, and right click could be used for other purposes by a 
content. Instead of always opening contextmenu, there could be other options 
like a menu option to show list of images to download, or copy the entire text. 
Content area should not be yours to play with unless you are given permission 
to do so. If you ignore fundamentals like this, Mozilla will be accepted only 
by a fraction of users out there and that fraction's fraction already includes 
you all. I have nothing else to say, but hope that a netscape Project manager 
reviews this before you guys manage to put this inside mozilla by only asking 1-
2 developer's okay.

Regarding comment 53, I think this approach is totallyu incorrect. If a web
designer does not want me to download an image from her page, she should not
post that image on the page. If she would like me to see but not download the
image, she must state it clearly in a copyright notice before giving access to
the imgae. This includes disabling all direct access to the image on the server
side.

In any case, a HTML tag to disable the context menu is NOT a legal agreement,
and the user agent may ignore it as it see fit. The content posted on the site
is the HTML source and image binary data, no more. In absence of a legal
agreement between the publisher and the user, the user and user agent have the
implict right to render this publically available data in any way they seem fit,
. In any case the user agent, as it's name implies, should be designed to the 
serve wishes of the user- not the web publisher. Therefore, the user agent must
not allow the web publisher to irreversibly disable or cripply its function.
Why did you pull it to legal perspective now? I am pointing to crippling a very 
useful feature of Mozilla. If you are concern about your legal rights, it is 
perfectly legitemate for you to use a browser which may 100% obey your legal 
way of thinking, like an alternative, Beonex perhaps. And my comments were not 
some approach, they are the acute facts themselves. Mozilla have no future if 
it does not get acceptance from enterprise and if Netscape drops it because of 
that, you will go to sourceforge.net and wait for hours for a browser download 
patched by a group of ideological egosteers. It will be marginalized overnite. 
Bora123: Can you name 1 site that has replaced the right click menu with
something usefull ?
There is freedom on both sides... a web developer is free to insert stupid
scripts that attempt to disable functionality for the user... and the user is
free to set his/her browser to ignore them.  It's a free 'Net...

Web developers who put such moronic scripts in place are the ones who are
"crippling a useful feature of Mozilla"... putting in the ability to disable
such things is *adding* a very useful feature to Mozilla.

#53, sounds like you're using these kind of eventhandler and fear that Mozilla
users might be given the power to easily use the context menu on your website :P

If someone absolutely wants to copy a webpage, there are various possibilities
tools to do so.
Why would an *option* to disable unwanted features lower Mozilla#s acceptance?

It is your right to not visit those websites that block the context menu. I see
it as my right to have _my_ browser that is not controlled by _anyone_ but myself.
I know many people that would love Mozilla even more for having such feature and
some who would switch from IE just to have great anti-annoyances settings.

Why would the context menu be part of the content? It offers actions Mozilla
executes, and not something the author of the website created.

As you can see if you take a look at the "Votes", the interest in this feature
is quite high - there are only 149 bugs with more than 22 votes.

Also, what's your problem with having the full control over your browser (#9,
#12, ...)? Sounds really like _you_ are having the problem here. Don't want the
control? Fine, don' enable the tweaks. But why should not others benefit from
it, and have a browser _they_ like, without the need to recompile?

You said you were done with this bug (#12), yet you continue argueing.

Regarding #55,
> it is perfectly legitemate for you to use a browser which may 100% obey your 
> legal way of thinking
why shpouldn't Mozilla be this browser?

Concerning the bug and the propoals, I find the meta-key idea to switch between
*my browser's* contextmenu and the possible replacement by the website quite
nice, however since I'm not a programmer myself I'm not the one to give advice
here. Personally I would be fine with just a pref to generally disable
oncontextmenu handler.


Sorry for voicing my opinion but after getting spammed (j\k) by your discussion
[yeah, my faul, I subscribed to this bug ;) ] and after reading #53 I felt the
urge to disburden myself.
First up, Bora123, before I even get into specific counter-arguments and
contradictions, your bombast ("I dont know! why dont you ask them? ") and
exaggeration ("It will be marginalized overnite.") are not helping. Even if you
consider the proposal(s) and argument(s) on which you are commenting to be
ridiculous, their authors do not. Please consider this when wording your
comments. Alternately, perhaps it would help if, as per your own suggestions on
two seperate occasions, you were to stop commenting on this bug entirely.

--

The entire "webpage authors have a _right_ to control how their publically
available page/application works on a users device" argument is bogus. If
authors did have such a right, then users would not have a right to view a page
that looked anything different to what the author intended; this would make
certain browser bugs a violation of authors' rights. This would also mean that
visually impired people and people using mobile or non-graphic devices would not
have the right to use the page. Much of Bora123's language is from the
standpoint that authors do have such a right, but as soon as legalities were
introduced, he didn't understand why.

To be advancing, now, the weaker argument that authors should simply have this
ability is hypocritical as it means arguing against this, but allowing to pass
all of the other items in Advanced/Scripts & Windows, plus cookie control, image
blocking and disabling of Java[script]/XSLT. (I accept the possibility that some
would see cookie control as special case.) These are all features that many
users desire and use _specifically_ because it allows them to frustrate
misbehaviour on the part of webpage authors. A paricularly interesting wrinkle
is that page authors can use the context-menu blocking to (presumably
inadvertently) prevent users from blocking banner ads. Part of this problem may
stem from a misunderstanding on Bora123's part that the context menu is part of
the "content", despite close to two decades of UI practice.

Speaking entirely for myself: for a long time my preferred means of going back a
page was to depress the right button, make a tiny clockwise motion with my right
wrist, then release. This generally happened so fast that the context menu never
even appeared, and was certainly faster than dragging the mouse up to the menu
bar. I am still a heavy user of the context menu, even if less so than before.
It's also true that I like the GIMP with its deep and near-complete context
menu. Others may differ, but I suspect that a great many people depend upon
being able to have the context menu function correctly (correct in the sense of
the principle of least surprise).

Bora123 made another odd argument (read: non sequiter) about access to port 80.
Switching to port 443 is somewhat irrelevant against content "theft". Very few
people would ever attempt to "steal" an image with a telnet client; if not their
normal browser, I imagine they'd ordinarily use wget, lynx or links - all of
which are SSL-enabled. It would appear that the demark is pretty obvious: the
author should control what goes out of port 80/443/etc., the user should control
how the content is made to appear on his/her device.

Various posters have made suggestions which appeal:

- If it is reasonable for the user to decide whether or not a webpage author can
override right-mouseclicks, it is probably reasonable to extend the same choice
over the other buttons, either at a per-button granularity or all-in-one.

- The Advanced/Scripts & Windows preferences sheet is an excellent (dare I say
"obvious"?) place to put such an option, if is to be placed in the UI at all.
Whilst I am sympathetic to Lasse's suggestion that the option should default to
preventing webpage authors from having any control at all, I think that it makes
sense for Mozilla to continue its approach of turning all author-accessible
features on by default and allowing users to selectively disable them.

- The Shift as "I really mean it" modifier has a precendent of sorts in Shift
Reload causing the cache-prevention headers to be included in the request. As a
user when I find the need to use this, my way of thinking is "Yes, _really_
reload". In the same sense, "Yes, _really_ give me the context menu" has a
certain appeal, if there aren't other dire consequences. This would also allow
web-app developers to build what they want, but still leave users able to make
use of the browser's interface; the browser being an application too, and one
that ought to be representing the user's wishes where possible. This also plays
well with the original intent of #72084 being about inadvertence.

I thank you for your crisitism over my arguments Mr.Turner.  I understand the 
difficulties you have had with right click disabled pages and your concerns on 
visually impaired. However, there are other versions of browsers out there 
which will satisfy specific needs, and you have just skipped that argument 
throughly. I understand your fixation on Mozilla, it is the human nature 
perhaps. But we have to think the future of this browser not the specific 
individual's wish lists. I do not know how well of a DOM programmer are you, 
but I am telling you next year or so there will be unignorable applications 
written in Browsers and they will demand right click to be available for 
somethingelse other than the obvious.

regards,
@bora123

Could you please name just one single case where there is any use (for the user)
in not letting her chose to have a context menu.
If not, *please* stop trolling.
Re comment 60:

OK... if there are some (hypothetical) applications that won't work correctly if
the user overrides the site's attempted alteration/disabling of the right-click
menu, then any user wishing to use such sites will need to turn off this
feature.  The instructions and help screens for that site/application may need
to make this clear.  If a user keeps the feature in a setting that interferes
with the functionality of the application, then it will be the user's fault if
the application doesn't work.

This doesn't mean that Mozilla shouldn't have the capability of letting the user
configure this feature, just as it already has configuration settings for such
things as blocking images, popups, and cookies, which potentially may make
certain sites (especially those that consider themselves "applications") to fail
to work.  The user has a tradeoff to consider between possibly interfering with
the functionality of sites versus putting up with annoyances that could be
disabled.  In the end, it's the user's choice to make.

As for the presence or absence of this feature affecting the future of Mozilla,
I think Mozilla's future is much brighter if it has a wider range of features
allowing the user to have more control of the browsing experience, instead of
being forced into passively accepting whatever trendy idiocies get pushed on it
by Web authors.  Microsoft has already cornered the market for software designed
in the mindset of "Where do we want to force you to go today?" [tm].  Mozilla
will get more people switching to it as they realize it lets them gain more
control instead of surrendering it.
I too think there should be an option (like the popup blocking) to disallow web
sites from interfering with the user interface.

here is an example: 
http://www.music4games.net/f_garritan_orchestralstrings.html

It both blocks right clicks and *selecting*. Now THAT is very annoying.
IMHO the only argument against disallowing fiddling with the mouse is comment
#21, which sais: 'If the users can go back and forward, my stateful application
will break.'

Before designing such an application though, be aware of the fact that http is
not stateful at all. You can use cookies to keep some state, but still it just
isn't designed to do what you want.

If you want to be stateful, all you can do is write it in javascript and put it
all in one big page. It'll keep its state, for as long as your page is on
screen. Or if you want to be fancy, use XUL. Just don't expect to use simple
html and http to do what you want. It won't.

Look at some of the better (IMO) web applications, like bugzilla itself. Press
back and forward all you like, it'll still work! The worst thing that that can
happen is that something will be submitted twice. The coders could even prevent
that by using formkeys (one time keys in hidden input fields).

Other working applications:
- sneakemail.com
- slash

more?
my god, onclick return false also block caret browsing, any bug on this?
->default owner
Assignee: joki → saari
Target Milestone: mozilla1.1alpha → mozilla1.4beta
I have read all the comments but I'm not wiser as to how this has been/will be
solved. Of course web developers must have access to modify or block or replace
the context menu with a menu of their own. It IS a CONTEXT menu.

But if you want to tuck in a "disallow scripts to disable the context menu",
that's fine with me as long as it's not a DEFAULT option.
> Of course web developers must have access

That's what web developers all say.  And all the users say, "No, this is _my_
context menu with options that _I_ want in it."  Therein lies the core conflict.
I don't really see the core conflict.  The user selects his browser not the
website developer.  Therefore the application should be written for the user not
the website developer.

The only reason I switched to Mozilla is the Preferences/Advanced/Scripts &
Plugins options page.  Those options elude to a design philosophy that I wanted
in my browser.

Which ever browser exists that most closely adheres to that philosophy will be
the brower I use.
> The user selects his browser not the website developer.  

And the developer chooses which browser he supports. If he sees that something
is not possible with some browser he will say that you must use another one in
order to access that site.

You'll say: "Then I won't go to that site". 
Fine, you can do the same right now.

I think that everyone here wants Mozilla to be a better browser, so let's stop
saying "I'm right and you're wrong"
> Of course web developers must have access to modify or block or replace
> the context menu with a menu of their own.

Of course.

And of course email authors must have access to modify or block or replace the
context menu of the receiver's email client.

And let's allow PNG images to modify or block or replace the context menus of
our image viewers.

And I'm sure we all agree that TV stations desperately need the ability to
reprogram the buttons on your remote control.

Why do so many "web developers" think they have a constitutional right to
control every aspect of how *my* computer behaves? You're writing HTML, not an
operating system! There is a difference, despite Microsoft's efforts to make you
believe otherwise.

(For the record, I'm a professional web developer.)
Jonas, I can see how your reasoning but I don't think we can compare mediums
which are static and passive to a medium which is built for interaction.

I build applications which run in browsers and all I want is to be able to
provide the same features and functions to Mozilla and Explorer users (which in
this particular case is a customized contextual menu). Of course I can remove
those functions for Mozilla users, but it just doesn't feel right. 

BTW, Doesn't digital-tv let the content providers change the functionality of
some of the buttons on the users remote/box ;)
> And the developer chooses which browser he supports

the e-commerce site developer chooses which browser he supports based on: 
a. the controls the browser gives him over the user
or 
b. the percent of market share the users of that browser represents?

Is there a w3c standard somewhere thats says the browser must give control of
the context menu to a website developer?

If a browser wants to put in the option of enabling users to hand over control
of the context menu for some specific IPs, so that companies can do stuff on
internal applications, fine.

But to allow any random site to take control of the context menu by default is
not consistent with the philosophy that lead to the options provided to Mozilla
users in Preferences/Advanced/Scripts tab.
I like the Preferences/Advanced/Scripts options and i think that it should be 
possible to block sites from intercepting the right and middle clicks.  (But it 
should be off by default)
*** Bug 190754 has been marked as a duplicate of this bug. ***
*** Bug 192019 has been marked as a duplicate of this bug. ***
*** Bug 194037 has been marked as a duplicate of this bug. ***
*** Bug 195805 has been marked as a duplicate of this bug. ***
*** Bug 195668 has been marked as a duplicate of this bug. ***
I have read most of the thread and it seems the whole thing
revolves around DRM.

Frankly, I do not agree with that arguement at all: If the
content needs to be kept private, there are other options
(encryption, login procedures etc). 

The reason why I would like the popup never disabled is to
be able to use tabbed windows without having to use a keyboard
shortcut + click. Did we not invent popups so that we could
click instead of pecking the kb? Why go back now?

And, I really fail to see the arguement that 'undisabled popup' 
should be made optional and be 'disableable' as default... 

Is this not a prime example of desiring security (!) by obscurity?

And, what security are we talking about?
Taking bug. I'm going to add an option to disable the oncontextmenu handler, but
the handler will be enabled by default. I'll add it to the Scripts & Plugins
pref panel.
Assignee: saari → mstoltz
Well, Great that is it! I have been waiting to hear this. That is why I like 
open source projects alot. People discusses for months on something, then one 
person comes out and says ok whatever, I am doing this, dont like it? go take 
the front! Well done, well done indeed. While at it, why not make an events tab 
on preferences, and make all the events not cancelable. That will add more onto 
the future success of Mozilla.


re: bora123@yahoo.com

I don't agree. Feature to block event cancel will likely lead to
regressions. For example, an XUL/HTML application may need to cancel
event that it trigger. Or an existing application may count on its
ability to cancel event to work properly. We'll probably need to
discuss if we need to keep track of where and how events are triggered,
event scope, etc. At this moment, we should enable blocking of event
cancel only if there is a need.
It's very simple.  He who writes the code makes the decisions.  This holds for
all projects; open and closed source alike.

The only difference is that with open source you're free to write the code
yourself if you want to be calling the shots.
>It's very simple.  

Yes it is. noone infact denies that.

>He who writes the code makes the decisions.  This holds for
>all projects; open and closed source alike.

I believe this is really not what you really meant. If individualism is the 
essence of an open project, that project is doomed anyways. On the other hand, 
what is the purpose of allowing people posting comments to the bugzilla 
alltogether then? 

>The only difference is that with open source you're free to write the code
>yourself if you want to be calling the shots.

Okey, alrighty then.
> I believe this is really not what you really meant. If individualism is the 
> essence of an open project, that project is doomed anyways.

I said exactly what I meant, modulo the fact that "he who writes the code" can
be a group of people.

Comments are read.  Sometimes they are acted on.  There is no obligation to do
the latter.
Mitchell,

I am glad that you decided that way. And, you are
correct (IMHO) in considering it a bug, rather than
a feature. It was, after all a case reduced functionality.

Thank you.

*** Bug 200017 has been marked as a duplicate of this bug. ***
FYI: on http://doa2.host.sk it's impossible to rightclick
URL: http://doa2.host.sk
Mitch, did you want to do this the way I approached it in attachment 101389 [details] [diff] [review]?  If
so, feel free to assign this to me since I already have it done that way in my
tree (UI included).
*** Bug 203582 has been marked as a duplicate of this bug. ***
*** Bug 207442 has been marked as a duplicate of this bug. ***
Comment on attachment 101389 [details] [diff] [review]
Concept patch

Chris's patch looks fine, just need to come up with a pref name. I propose
dom.disable_contextmenu_listeners.
Any objections? We should add a default pref in all.js too. It will default to
not blocking context menu listeners. Can I get an sr?
Attachment #101389 - Flags: superreview?(heikki)
Attachment #101389 - Flags: review+
Comment on attachment 101389 [details] [diff] [review]
Concept patch

caillon's patch looks fine to me, let's do it. For the pref name, I propose
dom.disable_contextmenu_listeners. Any objections? We need to add a default
pref to all.js too; I'll take care of that. It will default to false (don't
block the listeners).
Can I get an sr?
Comment on attachment 101389 [details] [diff] [review]
Concept patch

>Index: content/events/src/nsEventListenerManager.cpp
>===================================================================

I think IsCallerChrome() should be called earlier so that we wouldn't do all
that extra work to bail out at the end. If IsCallerChrome() is fast, how about:

+  if ((aSubType & NS_EVENT_BITS_CONTEXTMENU) &&
+      !nsContentUtils::IsCallerChrome()) {

My suggestion for a boolean pref name would be:

dom.event.contextmenu.enabled

Rationale:
 * This could easily be extended later for other DOM events
 * DOM event names actually don't include the "on" part
 * We could extend this for other properties regarding the event
Attachment #101389 - Flags: superreview?(heikki)
Attachment #101389 - Flags: superreview+
Shouldn't we return an error code, rather than NS_OK? (which may allow Web
monsters to check if oncontextmenu is blocked).

just a reminder: dom.*.enabled is reverse of dom.disable.* :-)

I guess it's now too late to ask dom.event.contextmenu.enabled to be true by
default eh?
Keywords: access
Returning an error code would cause script execution to stop.  So, no...  ;-)
Taking to land this.
Assignee: mstoltz → caillon
Comment on attachment 101389 [details] [diff] [review]
Concept patch

Erg, so this patch used to work but doesn't seem to anymore (at least for the
oncontextmenu="return false" case)...  Not sure why just yet.
Attachment #101389 - Attachment is obsolete: true
*** Bug 70135 has been marked as a duplicate of this bug. ***
*** Bug 209471 has been marked as a duplicate of this bug. ***
Blocks: patch-soap-opera
From an enterprise point of view please make sure that oncontextmenu events are
available via a preference or a security settings. Many Enterprises use this
feature for their internal and B2B web applications to provide their own menus.
The key here must be that what ever you decide to do, enable/disable by default
- it must be possible to allow the application to override the event easily,
without further installations.

Why not model this after popups, by default it allows an app to override the
oncontextmenus - when an application tries to do so, the user is informed "the
current page has tried to hijack your context menu, would you like to disable
this as default in your preferences" and then given the options "this page, this
domain, all pages"

Please dont underestimate the need for this.

Mark
mproctor@cisco.com
I just added a "restore context menu" bookmarklet to
http://www.squarefree.com/bookmarklets/zap.html.
Jesse: You rock! <grin>
Doesn't work on www.asianwarez.com
It has something to do with the frames...

If you access the resulting page directly
(http://ontherise.free.fr/explorer.html), it's ok.

I'm pretty sure I've seen some other other bookmarklets deal with frames, so
there should be some way to handle that.
Bookmarklets can only recurse into frames whose URL have the same domain as the
frameset.
*** Bug 215609 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
*** Bug 217836 has been marked as a duplicate of this bug. ***
*** Bug 220088 has been marked as a duplicate of this bug. ***
Is a preference really the best way to handle this?

Some sites may have a valid use for occasionally overriding oncontextmenu. A
pref would be all-or-nothing. And unless you're going to provide an status-bar
indicator like Firebird has for popups, a user could go unaware they are missing
functionality or content on a site.

My suggestion would be to leave right-click as is. The action defaults to the
context menu, but can be overridden by a web page. However, Ctrl+right-click
would always show the context menu. Control could act as sort of a 'force the
default' modifier. This could apply to the other mouse buttons as well, as I
believe they too can be overridden.
> My suggestion would be to leave right-click as is. The action defaults
> to the context menu, but can be overridden by a web page. However,
> Ctrl+right-click would always show the context menu. Control could act
> as sort of a 'force the default' modifier. This could apply to the
> other mouse buttons as well, as I believe they too can be overridden.

There may be valid reasons (even though I don't see any reason why some "web
designer" should interfere with my UI), but typically all those application are
abusive. So the option should be to change as suggested and not make it more
complicated as you describe, maybe the other way round. But the latter might be
too complicated and if you need it you can swith off the option anyway.

pi
Several Mozilla prefs have the effect of occasionally removing functionality
from sites without the user necessarily noticing it.  The anti-popup prefs, and
the hidden pref to disable the target="_blank" attribute opening new browser
windows, are like this; I have those set myself, and sometimes get temporarily
baffled at a site's behavior as a result.  Turning off JavaScript, images,
cookies, or other things that are disablable, can also produce silent loss of
functionality in sites not designed to gracefully degrade.  All of this doesn't
mean that these preferences shouldn't be provided; it's ultimately the user's
decision to decide between the annoyance of having sites do things and the
annoyance of having sites fail to do things.
The attached screenshot shows http://markl.f2o.org/Right_Click_Menu.html -
note that the site'e menu is shown where the right mouse button was clicked,
while Mozilla's menu appears on the far left edge of the window.

There are several advantages to this solution:
1. Both Mozilla and the website remain fully functional.
2. Easy for end users to understand.
3. There is no need to add prefs.
4. No keyboard shortcuts are wasted.

Prog.
> http://markl.f2o.org/Right_Click_Menu.html

I see this right mouse button overloading like a real annoyance. Web sites
should not be allowed to do so, or at least an option in the browser should be
provided to forbid such an overloading. I don't care if I lose functionnalities,
the web site should not rely on such annoying techniques and re-think its design.

Why is it annoying ? Because you lose your usual context menu, with all the nice
options you get there and you are used to. Give me my browser user interface back.

I am not sure if I would agree with the alternative offered by
prognathous@hotmail.com (right-click override/overload). I would
not mind if it was a button which displayed the site-specific popup,
but the moment it takes over my right-click action (forcing me to
use shift-right-click) I am totally alienated.

I must add, though, it does look an interesting feature. 

Yet, I really think some other UI solution needs to be found (say, 
automatically a different color etc) for the point that uses such 
right-click overriding. And, it should be part of the standard 
somehow.

Adem
a sample site that changes (not disables) the right click menu is
http://www.milonic.com , which is different from the example in Comment #63 (i
didn't notice any disabling on that example, however).

using milonic's menu, i can't copy a link location nor open the link in a new
tab with my mouse (though ctrl+click does still work).  however, the very nice
thing about this particular site is that you are allowed to disable their custom
menu.  i doubt many sites care enough to give users that option.
Blocks: 187917
*** Bug 225334 has been marked as a duplicate of this bug. ***
*** Bug 225293 has been marked as a duplicate of this bug. ***
*** Bug 225806 has been marked as a duplicate of this bug. ***
*** Bug 227422 has been marked as a duplicate of this bug. ***
Is this bug going anywhere? I notice it has a lot of votes, and I think that
there is enough justification for inclusion of some kind of workaround or fix in
Mozilla and Mozilla Firebird builds. There's no real reason why this shouldn't
be an option in the Web Features > Advanced section of Firebird and/or the
equivilent in Mozilla. Javascripts modifying the actions of mouse buttons is
extremely annoying, and ultimately doesn't stop anyone "stealing" any content,
as if protecting your content via that way was ever feasible anyway.
I like the idea of using "Ctrl+Right Click" to force the display of the context
menu. I first voted for this bug because I had in mind a lot of web sites which
overload the right click only to forbid the use of the context menu. However,
the right click may be used for a real feature. For example, here is a drawing
script which let you paint with a color on the left click, and another color
with the right click : http://mess.genezys.net/Drawer/
*** Bug 230379 has been marked as a duplicate of this bug. ***
*** Bug 231374 has been marked as a duplicate of this bug. ***
*** Bug 235219 has been marked as a duplicate of this bug. ***
I'd like to propose a summary change for this bug, to something like "Scripts & 
Plug-ins Preferences should have "Disable mouse right-click" option", 
or "Prevent websites from disabling the mouse right-click context menu".

That'd prevent people (like myself <g>) from filling duplicates. I did search 
for a duplicate, but got nothing.

Marcos.
> "Disable mouse right-click" option", 
> or 
> "Prevent websites from disabling the mouse right-click context menu"

I'd rather the wording be something like this:

"Allow websites to disable your right-click context menu"

Which means the default is to *not* let the websites disable 
your context menu.
*** Bug 236055 has been marked as a duplicate of this bug. ***
Summary: There is no way to always open the context menu upon right-click (oncontextmenu?) → Prevent websites from disabling the mouse right-click context menu - disallow sites access to Window.oncontextmenu and friends
Attached patch Better patch (obsolete) — — Splinter Review 
This taps right into the contextmenu code itself and does a much more thorough
job of tackling this problem.  If someone sets the pref (I like heikki's
suggestion for the name) then we functionally need to do the same thing as my
earlier patch, however since we are in the middle of contextmenu code which is
fired by chrome, the script context is always chrome, so I can't just check
whether the script context is chrome as I did before.  So we need to do things
manually and check the document principal of the event target node against the
system principal.
Attachment #132318 - Attachment is obsolete: true
Ok, this should be cleaned up enough for reviewing and pushing into the tree.
Attachment #142892 - Attachment is obsolete: true
Attachment #142937 - Flags: superreview?(bryner)
Attachment #142937 - Flags: review?(jst)
Comment on attachment 142937 [details] [diff] [review]
Patch for reviews

I do not see any change made to any .js file for the default value of the
preference...
That's because I'm not changing any default value.  You want it?  You do the
work to turn it on.  That means manually.  With about:config.  With whatever
pref name is checked in.
Note that this probably should get UI rather quickly.  Asa said he could get
someone to do that once this part landed.
Severity: major → normal
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: mozilla1.4beta → mozilla1.7beta
US is bug 86193
Comment on attachment 142937 [details] [diff] [review]
Patch for reviews

r=jst
Attachment #142937 - Flags: review?(jst) → review+
(In reply to comment #133)
> That's because I'm not changing any default value.  You want it?  You do the
> work to turn it on.  That means manually.  With about:config.  With whatever
> pref name is checked in.

How is a user supposed to know about the new pref's existence (until the UI is
in place)? Shouldn't it be added to all.js, with the default value being "true"
to preserve the current behaviour, and preferably with a comment explaining its
purpose? (Also, there is a bug somewhere for documenting all the prefs.)

Other than that nit, it's great! Thanks a lot for the work. This is very useful.
I don't like the idea having it a global pref. Why not making a configurable
security policy out of it? This would give the user more ability to fine-tune
the behaviour.
Comment on attachment 142937 [details] [diff] [review]
Patch for reviews

I think this patch does preserve the current behavior by default.  GetBoolPref
will fail with no default in all.js.  However, for clarity, I'd like to see the
default be added to all.js rather than being implicit in the code.

sr=bryner with that change.
Attachment #142937 - Flags: superreview?(bryner) → superreview+
Checked in 03/05/2004 18:58 PST.  Someone probably wants to file a new bug for
the UI (don't assign it to me, it will just sit around gaining dust).
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
So what does this patch actually DO? I don't see a description anywhere. Best I
can tell from the code itself, it's an all-or-nothing pref, as I greatly feared
(see my only other remarks, comment 111). I'm occasionally annoyed by sites
overriding my mouse buttons, but I would be even more annoyed about silently
losing site functionality. I'm very sad to say that I won't be able to use this
new pref at all, and sites co-opting my browser will remain a problem.
Jeremy Dolan, it seems to (haven't run it yet) completely disable all access of
sites to context menus, which is exactly what I (the bug reporter) asked for.
(Thanks caillon!, and sorry for my poor inaction on this bug.) You are free to
file a new bug about making the backend site-specific.

> file a new bug for the UI

Bug 236643
(In reply to comment #142)
> > file a new bug for the UI
> 
> Bug 236643

Bug 236643 is a duplicate of Bug 117532, which is in the dependency list of this
bug. 

In other words, Bug 117532 is about adding UI for this bug... 
I understand the right way to add this pref in prefs.js or user.js is:

user_pref("dom.event.contextmenu.enabled", true);

Is it correct? BTW, such info should always be _easily_ available in pref bugs
to help testing them.
I just fired up Stipe's unofficial 3/6 build (which does have this patch).
Setting seems to work great on the test site: http://doa2.host.sk
But the errors that appear in the JS Console

Error: uncaught exception: Permission denied to set property
HTMLDocument.oncontextmenu

Appear even when this pref is set to true, or not set (in other words, the error
is still thrown when the site is ALLOWED to set oncontextmenu). Shouldn't this
error only be thrown when the site is -not- allowed to do this?
Josh, you probably added a capability pref to block HTMLDocument.oncontextmenu
which you would need to remove -- this patch doesn't throw any exceptions
anywhere nor does it even go near the setting of anything.  This just hooks up
into the event dispatch code and makes sure that in cases where the event would
have been silently dropped without the pref set now will go through.
-> VERIFIED FIXED

Thanks! Works like a charm.
Status: RESOLVED → VERIFIED
(In reply to comment #144)
> I understand the right way to add this pref in prefs.js or user.js is:
> 
> user_pref("dom.event.contextmenu.enabled", true);

Wrong. You have to set it to false if you want to have always a context menu on
right click! The default in GRE\...\all.js is true.

Note: Attachment 142937 [details] [diff] (the patch) contains a typo in the pref name
(dom.event.contextmenu.enable instead of ~.enabled). That has confused me. But
the correct patch was checked in. :-)


Here's the layman's explanation:

1. In the address bar, type about:config and press Enter
2. Search for a Preference named dom.event.contextmenu.enabled
3. Double click its entry and change it to "false" (without the quotes)

Mozilla will now show the context menu even in pages that try to hide or replace it.

Prog.
Whiteboard: [p-ie/mac] → See comment 149 for instructions on how to use this option | [p-ie/mac]
The URL has moved. Correcting...
URL: http://doa2.host.sk → http://filesharing.megacodecpack.com/
Attached file testcase — 
even better, a testcase (dynamicdrive -alert())... and some more urls :P

http://www.dynamicdrive.com/dynamicindex9/noright.htm
http://www.mailmontage.com/index_test.html

this works great, many thanks to all!
One part appears not to be complete yet: when the context menu is opened after
the script handled the event, is is opened wherever the mouse is after, say, you
close an alert box, not necessarily where you first clicked, and will have
object-specific entries (view image etc) based on that second position. So the
image context menu blocker on dynamic drive sort of defeats it (unless you have
a spacebar key)
*** Bug 240356 has been marked as a duplicate of this bug. ***
It needs a way to differentiate between code running on web pages and in
extensions. In 1.7 rc1, the Tab Scroller extension does not work completely with
context menu-blocking-blocking enabled; the regular context menu opens after the
tab switches.
*** Bug 249749 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
Blocks: 326543
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: