FAQ Topic - How do I disable the right mouse button?
FAQ server
FAQ Topic - How do I disable the right mouse button?
-----------------------------------------------------------------------
The oncontextmenu intrinsic event is the only safe and reliable
method. Of the other approaches often presented, most depend on
an alert box interrupting the process and rarely work. Note that
oncontextmenu is a non-standard event and is not supported on
all browsers.
` <body oncontextmenu="return false"> `
===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://jibbering.com/faq/index.html.
The FAQ workers are a group of volunteers. The sendings of these
daily posts are proficiently hosted by www.pair.com.
Thomas 'PointedEars' Lahn
> The oncontextmenu intrinsic event
As I have pointed out in my still unanswered e-mail to both current FAQ
maintainers about 20 days ago (along with other suggestions and comments),
that wording is wrong. `oncontextmenu' is a proprietary event handler,
not an intrinsic event as defined by and in the HTML 4.01 Specification:
http://www.w3.org/TR/html401/interact/scripts.html#events
> is the only safe and reliable method.
As I also have pointed out, because it is proprietary and not standardized,
it runs the risk of being not well supported, if supported at all, and so it
is not a safe and reliable method at all.
> Of the other approaches often presented, most depend on
> an alert box interrupting the process and rarely work. Note that
> oncontextmenu is a non-standard event
It is a non-standard (i.e. proprietary) event *handler*. The corresponding
event would be `contextmenu'. It is just that the MSDN Library is unable to
make that important distinction to date (when MS begins to implement DOM
Level 2+ Events, they will finally have to.) In that sense, the HTML 4.01
Specification which uses the same (wrong) terminology has been updated by
the W3C DOM Level 2 Events Specification as indicated by the included note
in the aforementioned subsection of HTML 4.01:
http://www.w3.org/TR/DOM-Level-2-Events/
> and is not supported on all browsers.
There is the all-too-obvious contradiction to the above statements.
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
FAQEditor
> FAQ server wrote:
>> The oncontextmenu intrinsic event
>
> As I have pointed out in my still unanswered e-mail to both current FAQ
> maintainers about 20 days ago (along with other suggestions and comments),
> that wording is wrong.
20 days ago was about the time I changed the email address in the FAQ to
the current one. If you sent an email to the old address then it would
explain why I haven't received it. If you sent it to clj...@comcast.net
then I honestly do not know why I have not received it unless it didn't
have FAQ in the Subject line of the email. If you would, please forward
it or re-send it to clj...@comcast.net and make sure the Subject Line
has FAQ in it so that the spam filter doesn't catch it by mistake.
Although personally, I would prefer that comments regarding the FAQ -
and its contents - be posted to the group so that it can be reviewed and
commented on by the group.
<snip>
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
FAQ Notes: http://www.jibbering.com/faq/faq_notes/faq_notes.html
ECMAScript Language Specification via FAQ2.6
Randy Webb
>> The oncontextmenu intrinsic event
My personal vote: The entry is wrong from start to finish. The question
being:
"How do I disable the right mouse button?"
And the only technically correct answer can only be:
"You can't".
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Bart Van der Donck
> Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:
>
>> FAQ server wrote:
>>> The oncontextmenu intrinsic event
>
> My personal vote: The entry is wrong from start to finish. The question
> being:
>
> "How do I disable the right mouse button?"
>
> And the only technically correct answer can only be:
>
> "You can't".
My personal vote is to keep
<body oncontextmenu="return false">
--
Bart
Dr J R Stockton
Tue, 4 Sep 2007 08:51:52, Randy Webb <HikksNo...@aol.com> posted:
>Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:
>> FAQ server wrote:
>>> The oncontextmenu intrinsic event
>
>My personal vote: The entry is wrong from start to finish. The question
>being:
>
>"How do I disable the right mouse button?"
>
>And the only technically correct answer can only be:
>
>"You can't".
A most irresponsible suggestion. Of course a script can disable the
right mouse button, or at least prevent it showing the usual menu. One
condition is sufficient, though probably not entirely necessary : that
the browser be IE6 running in XP sp2.
For me, <body oncontextmenu="return false"> disables it in IE6,
but not in Opera 9.23.
Therefore, an acceptable answer giving that code must state clearly that
it works in some but not all browsers.
Consider -
User, viewing page : The right mouse button does not now work!
Adviser, reading FAQ : It cannot be disabled; it must be broken.
--
(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)
Randy Webb
> In comp.lang.javascript message <4qWdnQ4jxLg...@giganews.com>,
> Tue, 4 Sep 2007 08:51:52, Randy Webb <HikksNo...@aol.com> posted:
>> Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:
>>> FAQ server wrote:
>>>> The oncontextmenu intrinsic event
>> My personal vote: The entry is wrong from start to finish. The question
>> being:
>>
>> "How do I disable the right mouse button?"
>>
>> And the only technically correct answer can only be:
>>
>> "You can't".
>
> A most irresponsible suggestion.
It isn't a "suggestion", it is fact. You can not disable my right mouse
button. Although you are welcome to try to prove me wrong.
> Of course a script can disable the right mouse button,
No it doesn't. Nor can it. Remember that this discussion got started
because Thomas wanted it semantically/technically correct.
> or at least prevent it showing the usual menu.
It doesn't do that either. Reverse the mouse buttons and you can still
get that menu if you disable the right mouse button (try it).
> One condition is sufficient, though probably not entirely necessary :
> that the browser be IE6 running in XP sp2.
Does that imply that it won't work in IE7 then?
> For me, <body oncontextmenu="return false"> disables it in IE6,
> but not in Opera 9.23.
That is because Opera does not allow mucking with the contextmenu's
and/or mouse actions. And, the above code has nothing to do with the
right mouse button. It prevents the context menu from showing.
> Therefore, an acceptable answer giving that code must state clearly that
> it works in some but not all browsers.
And it doesn't have to say that it is useless, easily circumvented, and
violates accessibility guidelines? You can reverse the mouse buttons in
Windows via the Control Panel. (Control Panel>Mouse>Button
Configuration). Mostly it is for left handed people. You have just made
navigation in your page impossible if you "disable the right mouse button".
Dr J R Stockton
Tue, 4 Sep 2007 21:39:29, Randy Webb <HikksNo...@aol.com> posted:
>Dr J R Stockton said the following on 9/4/2007 6:16 PM:
>> In comp.lang.javascript message <4qWdnQ4jxLg...@giganews.com>,
>> Tue, 4 Sep 2007 08:51:52, Randy Webb <HikksNo...@aol.com> posted:
>>> Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:
>>>> FAQ server wrote:
>>>>> The oncontextmenu intrinsic event
>>> My personal vote: The entry is wrong from start to finish. The question
>>> being:
>>>
>>> "How do I disable the right mouse button?"
>>>
>>> And the only technically correct answer can only be:
>>>
>>> "You can't".
>> A most irresponsible suggestion.
>
>It isn't a "suggestion", it is fact. You can not disable my right mouse
>button. Although you are welcome to try to prove me wrong.
The word you need is "cannot", implying impossibility. Use of "can not"
means a lack of inevitability. The distinction is important to the
literate.
>> Of course a script can disable the right mouse button,
>
>No it doesn't. Nor can it. Remember that this discussion got started
>because Thomas wanted it semantically/technically correct.
>
>> or at least prevent it showing the usual menu.
Don't respond in the middle of a statement of that nature.
>It doesn't do that either. Reverse the mouse buttons and you can still
>get that menu if you disable the right mouse button (try it).
>
>> One condition is sufficient, though probably not entirely necessary :
>>that the browser be IE6 running in XP sp2.
>
>Does that imply that it won't work in IE7 then?
No. It means what it says.
>> For me, <body oncontextmenu="return false"> disables it in IE6,
>> but not in Opera 9.23.
>
>That is because Opera does not allow mucking with the contextmenu's
>and/or mouse actions. And, the above code has nothing to do with the
>right mouse button. It prevents the context menu from showing.
>
>> Therefore, an acceptable answer giving that code must state clearly that
>> it works in some but not all browsers.
>
>And it doesn't have to say that it is useless, easily circumvented, and
>violates accessibility guidelines?
No; if I had meant that, I would have written so,
> You can reverse the mouse buttons in Windows via the Control Panel.
>(Control Panel>Mouse>Button Configuration). Mostly it is for left
>handed people. You have just made navigation in your page impossible if
>you "disable the right mouse button".
That effect is generally undesirable (though navigation without a mouse
is possible, especially on a page designed for it). But you have now
changed your mind, admitting that it can be disabled.
Perhaps when you write "You can't", you mean "You mustn't".
Probably the Question should be changed to something for which an
accurate, useful, and reasonably brief answer can be given.
If you want to answer "How can I protect my source from being copied?",
then "ask" that question. The answer can include mention of said
button, for those who search for that.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
FAQEditor
> Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:
>> FAQ server wrote:
>>> The oncontextmenu intrinsic event
>>
>> As I have pointed out in my still unanswered e-mail to both current FAQ
>> maintainers about 20 days ago (along with other suggestions and
>> comments),
>> that wording is wrong.
>
> 20 days ago was about the time I changed the email address in the FAQ to
> the current one. If you sent an email to the old address then it would
> explain why I haven't received it. If you sent it to clj...@comcast.net
> then I honestly do not know why I have not received it unless it didn't
> have FAQ in the Subject line of the email. If you would, please forward
> it or re-send it to clj...@comcast.net and make sure the Subject Line
> has FAQ in it so that the spam filter doesn't catch it by mistake.
Have you tried to resend that email? I have not yet received any from you.
Thomas 'PointedEars' Lahn
> FAQEditor said the following on 9/4/2007 8:43 AM:
>> Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:
>>> FAQ server wrote:
>>>> The oncontextmenu intrinsic event
>>> As I have pointed out in my still unanswered e-mail to both current FAQ
>>> maintainers about 20 days ago (along with other suggestions and
>>> comments),
>>> that wording is wrong.
>> 20 days ago was about the time I changed the email address in the FAQ to
>> the current one. If you sent an email to the old address then it would
>> explain why I haven't received it. If you sent it to clj...@comcast.net
>> then I honestly do not know why I have not received it unless it didn't
>> have FAQ in the Subject line of the email. If you would, please forward
>> it or re-send it to clj...@comcast.net and make sure the Subject Line
>> has FAQ in it so that the spam filter doesn't catch it by mistake.
>
> Have you tried to resend that email? I have not yet received any from you.
Sorry, I'm currently too busy doing my (RL) job.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:
>> FAQ server wrote:
>>> The oncontextmenu intrinsic event
>> As I have pointed out in my still unanswered e-mail to both current FAQ
>> maintainers about 20 days ago (along with other suggestions and comments),
>> that wording is wrong.
>
> 20 days ago was about the time I changed the email address in the FAQ to
> the current one. If you sent an email to the old address then it would
> explain why I haven't received it. If you sent it to clj...@comcast.net
> then I honestly do not know why I have not received it unless it didn't
> have FAQ in the Subject line of the email. If you would, please forward
> it or re-send it to clj...@comcast.net and make sure the Subject Line
> has FAQ in it so that the spam filter doesn't catch it by mistake.
>
> Although personally, I would prefer that comments regarding the FAQ -
> and its contents - be posted to the group so that it can be reviewed and
> commented on by the group.
Here you are:
---------------------------------------------------------------------------
Message-ID: <46C31C7C...@PointedEars.de>
Date: Wed, 15 Aug 2007 17:32:12 +0200
From: Thomas 'PointedEars' Lahn <******************>
Reply-To: Thomas 'PointedEars' Lahn <*******************>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6)
Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: clj...@ctvea.net
CC: j...@jibbering.com
Subject: Suggestions for the comp.lang.javascript FAQ
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=sha1; boundary="------------ms000907080800040308070406"
This is a cryptographically signed message in MIME format.
--------------ms000907080800040308070406
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Hello Randy,
Hello Jim,
here are some of my comments to and suggestions for the cljs FAQ and the
FAQ Notes.
Regarding the FAQ:
| 4.24 I have <a href="javascript:somefunction()"> what ... ?
|
| Whatever the rest of your question, this is generally a very bad use of
| the javascript pseudo protocol. It was designed so that a function could
| return a new page.
Replace "page" with "HTML document" (s/page/HTML document/)
| For example: javascript:"<p>Hello</p>" . Using it simply to call a
| function when a link is clicked causes an error in user agents that do not
| support javascript, or have javascript disabled.
That is *not* what happens. Instead, the following cases can occur:
A) No script support or no support for the proprietary `javascript:':
Error message (e.g. in IE 4 with enabled script support)
B) Disabled script support (that requires script support being present,
and usually implies support for "javascript:"):
Animations and other multimedia elements stop working.
Nothing else happens.
C) Script support present and enabled:
Animations and other multimedia elements stop; further accesses
to `location' may fail; other (non-script) links may fail.
Reason: there is no base for (relative) URIs references anymore.
(reported several in de.comp.lang.javascript)
| 4.26 How do I detect Opera/Netscape/IE?
Iff necessary, Netscape 4.x can currently be detected by evaluating
document.layers.
Iff necessary, Opera can currently be detected by evaluating window.opera.
| 4.27 How do I disable the right mouse button?
|
| The oncontextmenu intrinsic event is the only safe and reliable method.
`oncontextmenu' is _not_ an intrinsic event (as specified using this term
starting in HTML 4.01). Instead, it is a (currently) *proprietary* event
_handler_. Whether that could be considered "safe and reliable" is beyond me.
| Note that oncontextmenu is a non-standard event and is not supported on
| all browsers. <body oncontextmenu="return false">
A clear statement that this is not Valid HTML and, more important, not Valid
XHTML unless the attribute is defined in an internal subset, is missing.
Not Valid XML-based markup can make a validating parser to stop parsing
where the first error occurs.
| 4.28 How do I change the confirm box to say yes/no or default to cancel?
It should be added that OK/Cancel may lead to confusion if used with the
wrong question:
Do you want to cancel this operation?
[ OK ] [ Cancel ]
Now what? :)
| 4.37 How do I POST a form to a new window?
|
| You use the target attribute on the form, opening a window with that name
| and your feature string in the onsubmit handler of the FORM.
|
| <form ... target="wndname"
| onsubmit="window.open('',this.target,'features');return true;">
This should be changed so that it is made clear that an omitted `action'
attribute renders the markup not Valid.
<form action="..." target="..."
onsubmit="window.open('', this.target, 'features'); return true;">
window.open() is also a host object's method that should be tested for, and
one that works asynchronously (if it works). The FAQ should advise that a
wrapper method that does the test and maybe submits the form on timeout is
better than "literally" including the example in one's markup.
| 4.38 How do I download a page to a variable?
|
| Within a web-page, you need to either use java, or the XML HTTP Request
| object, see:
s/a web-page/an (X)HTML document/
I don't see a valid reason why _J_ava should be mentioned first here, or
mentioned at all for that matter. If it is mentioned, one could mention
any programming language that allows to make HTTP requests, especially
server-side (e.g. PHP).
IMHO, mentioning "java" only has the potential to deepen the confusion of
the reader between Java and JavaScript.
| 4.42 How do I open a new window with javascript?
|
| New windows can be opened on browsers that support the window.open
| function and are not subject to the action of any pop-up blocking
| mechanism with code such as:-
|
| if(window.open){
| wRef = window.open("http://example.com/page.html","windowName");
| }
Either none or a better feature test should be advised, such as
if (/\b(function|object)\b/i.test(typeof window.open) && window.open)
{
wRef = window.open("http://example.com/page.html", "windowName");
}
| 4.43 How do I get my browser to report javascript errors?
|
| [...]
| There is also a Firebug extension for Mozilla based browsers:
| http://www.getfirebug.com/
It should be noted that there is the Firebug console for IE and Opera which
may help with debugging scripts there.
[SN: The online resources listed in subsection 3.2 include links to
debuggers. These should be referred to in 4.43 (as well).]
| 4.44 What is AJAX?
s/page/document/
Probably there are more instances of this.
Regarding the FAQ Notes:
- http://www.jibbering.com/faq/faq_notes/clj_posts.html
| Additional Reading
Sometimes the <~> character is percent-encoded (%7E), sometimes it is not.
RFC3986, section 2.3, recommends *against* encoding it.
| Related draft proposals / work in progress:-
The links are broken. You should employ a tool such as
http://validator.w3.org/checklink before announcing a
new FAQ/FAQ Notes version.
- A better URI management is indicated, maybe using Content Negotiation.
For example, why not
http://www.jibbering.com/faq/notes/
and
http://www.jibbering.com/faq/notes/postings
instead of
http://www.jibbering.com/faq/faq_notes/faq_notes.html
and
http://www.jibbering.com/faq/faq_notes/clj_posts.html?
Thank you for taking the time. I am looking forward to your reply.
Regards,
PointedEars
[snipped PKCS7 signature]
---------------------------------------------------------------------------
David Mark
> Dr J R Stockton said the following on 9/4/2007 6:16 PM:
>
> > Tue, 4 Sep 2007 08:51:52, Randy Webb <HikksNotAtH...@aol.com> posted:
> >> Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:
> >>> FAQ server wrote:
> >>>> The oncontextmenu intrinsic event
> >> My personal vote: The entry is wrong from start to finish. The question
> >> being:
>
> >> "How do I disable the right mouse button?"
>
> >> And the only technically correct answer can only be:
>
> >> "You can't".
Right. It's the wrong question. It should be "How do I disable the
context menu."
>
> > A most irresponsible suggestion.
>
> It isn't a "suggestion", it is fact. You can not disable my right mouse
> button. Although you are welcome to try to prove me wrong.
>
> > Of course a script can disable the right mouse button,
>
> No it doesn't. Nor can it. Remember that this discussion got started
> because Thomas wanted it semantically/technically correct.
>
> > or at least prevent it showing the usual menu.
>
> It doesn't do that either. Reverse the mouse buttons and you can still
> get that menu if you disable the right mouse button (try it).
This is not true. Software applications get the correct logical
button, regardless of which physical button generated the event. I
just tested it with my context function. I would have been shocked if
it failed for IE as the event is "contextmenu" and there is no need to
detect the button in JavaScript. It didn't break in the other agents
that use mouseup and button detection either. For the record, I have
tested in IE5, IE5.5, IE6, IE7, Firefox 2, Netscape 9, Opera 9 and
Safari Beta on Windows and all work with this logic in a contextmenu/
mouseup handler:
e = e || global.event;
if ((e.which == 3 || e.button & 4) || e.type == 'contextmenu') ...
If memory serves me right, at least one non-IE browser (Opera I think)
supports the contextmenu event. So you have to deal with cases where
both events fire. I believe the above works for Mac's as well,
despite the fact that most (all?) have a single mouse button. IIRC,
to generate a context click requires holding the button for a few
seconds. Certainly it should work in Mac IE if it supports the
contextmenu event.
There just is no one-line solution that is suitable for a FAQ entry on
how to disable the context menu. And there is definitely no answer
for how to disable a physical right click (or even a logical context
ckick.)
And I think it should be noted that it is insane to handle context
clicks unless you implement a custom context menu (and it is a very
rare case where that is appropriate.)
FAQEditor
> FAQEditor wrote at 2007-09-04 08:43 GMT-0500:
>> Thomas 'PointedEars' Lahn said the following on 9/3/2007 8:14 PM:
>>> FAQ server wrote:
>>>> The oncontextmenu intrinsic event
>>> As I have pointed out in my still unanswered e-mail to both current FAQ
>>> maintainers about 20 days ago (along with other suggestions and comments),
>>> that wording is wrong.
>> 20 days ago was about the time I changed the email address in the FAQ to
>> the current one. If you sent an email to the old address then it would
>> explain why I haven't received it. If you sent it to clj...@comcast.net
>> then I honestly do not know why I have not received it unless it didn't
>> have FAQ in the Subject line of the email. If you would, please forward
>> it or re-send it to clj...@comcast.net and make sure the Subject Line
>> has FAQ in it so that the spam filter doesn't catch it by mistake.
>>
>> Although personally, I would prefer that comments regarding the FAQ -
>> and its contents - be posted to the group so that it can be reviewed and
>> commented on by the group.
>
> Here you are:
>
> ---------------------------------------------------------------------------
<snip>
> This is a cryptographically signed message in MIME format.
That never would have gotten to me even if the address hadn't changed.
> Hello Randy,
> Hello Jim,
>
> here are some of my comments to and suggestions for the cljs FAQ and the
> FAQ Notes.
>
> Regarding the FAQ:
>
> | 4.24 I have <a href="javascript:somefunction()"> what ... ?
> |
> | Whatever the rest of your question, this is generally a very bad use of
> | the javascript pseudo protocol. It was designed so that a function could
> | return a new page.
>
> Replace "page" with "HTML document" (s/page/HTML document/)
Changed locally to "document". It isn't necessarily an HTML document
that is returned but simply a document.
> | For example: javascript:"<p>Hello</p>" . Using it simply to call a
> | function when a link is clicked causes an error in user agents that do not
> | support javascript, or have javascript disabled.
>
> That is *not* what happens. Instead, the following cases can occur:
> A) No script support or no support for the proprietary `javascript:':
I don't see your intent with labeling so many things as "proprietary"
when 99% of what is in Javascript is/can/could be deemed as
"proprietary" but okay.
> Error message (e.g. in IE 4 with enabled script support)
Do you think IE4 is a good basis in 2007 for any argument at all? Even
though the point is valid, the basis isn't a good one. It probably
"fails" in any browser pre-1996 or so.
> B) Disabled script support (that requires script support being present,
> and usually implies support for "javascript:"):
>
> Animations and other multimedia elements stop working.
> Nothing else happens.
Are you saying that with scripting disabled that "Nothing else happens"?
I can't duplicate that in IE7 as what I get (even with scripting
completely disabled and no active content from the local drive or CD
drive) is that annoying little box asking me if I want to allow active
content to be executed.
Rather than list all of the potential problems with the javascript:
pseudo-protocol, would it be better to have a short entry along the
lines of:
<proposal>
Due to the problems that can arise from the use of the javascript:
pseudo-protocol it is best to avoid it. For some examples of the many
problems that it can cause, please see:
<URL: Url To a Notes page here>
</proposal>
And then move the rest of the entry into a Notes page?
> | 4.26 How do I detect Opera/Netscape/IE?
>
> Iff necessary, Netscape 4.x can currently be detected by evaluating
> document.layers.
No, Nescape 4.x is not the only browser that supports document.layers
There is even a browser that will pass this test:
if(document.layers && document.all){
alert('Go figure');
}
> Iff necessary, Opera can currently be detected by evaluating window.opera.
That is true. But, is it a good idea to tell how to detect a browser in
an entry that attempts to discourage the practice of browser detecting?
> | 4.27 How do I disable the right mouse button?
> |
> | The oncontextmenu intrinsic event is the only safe and reliable method.
>
> `oncontextmenu' is _not_ an intrinsic event (as specified using this term
> starting in HTML 4.01). Instead, it is a (currently) *proprietary* event
> _handler_. Whether that could be considered "safe and reliable" is beyond me.
>
> | Note that oncontextmenu is a non-standard event and is not supported on
> | all browsers. <body oncontextmenu="return false">
>
> A clear statement that this is not Valid HTML and, more important, not Valid
> XHTML unless the attribute is defined in an internal subset, is missing.
> Not Valid XML-based markup can make a validating parser to stop parsing
> where the first error occurs.
I have already stated my opinion (personal) with regards to that entry
whereby the only *correct* answer to the question is:
You can't.
Anything beyond that is merely child's play in an attempt to disable the
mouse button in a misguided attempt to disable the context menu.
> | 4.28 How do I change the confirm box to say yes/no or default to cancel?
>
> It should be added that OK/Cancel may lead to confusion if used with the
> wrong question:
>
> Do you want to cancel this operation?
>
> [ OK ] [ Cancel ]
>
> Now what? :)
The entry already suggests that you word the question such that "OK" is
suitable as the default answer. Meaning, that OK should be the default
answer to your question.
<quote>
However, you should be able to change the question so that "OK" is
suitable as the default.
</quote>
> | 4.37 How do I POST a form to a new window?
> |
> | You use the target attribute on the form, opening a window with that name
> | and your feature string in the onsubmit handler of the FORM.
> |
> | <form ... target="wndname"
> | onsubmit="window.open('',this.target,'features');return true;">
>
> This should be changed so that it is made clear that an omitted `action'
> attribute renders the markup not Valid.
I think a better alternative would be to add an acceptable action
attribute. It could also be argued that the ... ellipsis covers that
scenario.
> <form action="..." target="..."
> onsubmit="window.open('', this.target, 'features'); return true;">
The action attribute (isn't that deprecated somewhere?) has been added
to the entry.
<form action="..." target="wndname"
> window.open() is also a host object's method that should be tested for, and
> one that works asynchronously (if it works). The FAQ should advise that a
> wrapper method that does the test and maybe submits the form on timeout is
> better than "literally" including the example in one's markup.
The direct aspect of window.open (and the problems with it) is covered
explicitly in 4.42 "How do I open a new window with javascript?"
I do think there needs to be an entry specifically dedicated to feature
detection. It is touched on in 4.25 but I think it could benefit from an
entry of its own:
<proposal>
How do I know if a browser supports the feature I want to use?
Answer: Feature detection.......
</proposal>
Anybody have a proposal for an answer to it?
> | 4.38 How do I download a page to a variable?
> |
> | Within a web-page, you need to either use java, or the XML HTTP Request
> | object, see:
>
> s/a web-page/an (X)HTML document/
>
> I don't see a valid reason why _J_ava should be mentioned first here, or
> mentioned at all for that matter. If it is mentioned, one could mention
> any programming language that allows to make HTTP requests, especially
> server-side (e.g. PHP).
> IMHO, mentioning "java" only has the potential to deepen the confusion of
> the reader between Java and JavaScript.
Reference to Java removed entirely. Although the entry is still
incomplete and inadequate. There are more ways, with just javascript, to
download a page than the XHR Object.
> | 4.42 How do I open a new window with javascript?
> |
> | New windows can be opened on browsers that support the window.open
> | function and are not subject to the action of any pop-up blocking
> | mechanism with code such as:-
> |
> | if(window.open){
> | wRef = window.open("http://example.com/page.html","windowName");
> | }
>
> Either none or a better feature test should be advised, such as
>
> if (/\b(function|object)\b/i.test(typeof window.open) && window.open)
> {
> wRef = window.open("http://example.com/page.html", "windowName");
> }
Richard Cornford wrote that entry and if he agrees, I will change it.
Personally, the feature test there is overboard and overkill.
> | 4.43 How do I get my browser to report javascript errors?
> |
> | [...]
> | There is also a Firebug extension for Mozilla based browsers:
> | http://www.getfirebug.com/
>
> It should be noted that there is the Firebug console for IE and Opera which
> may help with debugging scripts there.
URL's to them?
> [SN: The online resources listed in subsection 3.2 include links to
> debuggers. These should be referred to in 4.43 (as well).]
>
> | 4.44 What is AJAX?
>
> s/page/document/
>
> Probably there are more instances of this.
There probably are. Suggested URL's to add?
> Regarding the FAQ Notes:
>
> - http://www.jibbering.com/faq/faq_notes/clj_posts.html
>
> | Additional Reading
>
> Sometimes the <~> character is percent-encoded (%7E), sometimes it is not.
> RFC3986, section 2.3, recommends *against* encoding it.
I will look into changing them all as time permits me to do so.
> | Related draft proposals / work in progress:-
>
> The links are broken. You should employ a tool such as
> http://validator.w3.org/checklink before announcing a
> new FAQ/FAQ Notes version.
> - A better URI management is indicated, maybe using Content Negotiation.
>
> For example, why not
>
> http://www.jibbering.com/faq/notes/
> and
> http://www.jibbering.com/faq/notes/postings
>
> instead of
>
> http://www.jibbering.com/faq/faq_notes/faq_notes.html
> and
> http://www.jibbering.com/faq/faq_notes/clj_posts.html?
The main reason is that Jim is not a big fan of changing URL's that are
established and I agree with him. I won't go rearranging his server.
Dr J R Stockton
Sat, 6 Oct 2007 23:02:20, FAQEditor <clj...@comcast.net> posted:
>Thomas 'PointedEars' Lahn said the following on 10/6/2007 6:06 PM:
>> Iff necessary, Opera can currently be detected by evaluating window.opera.
>
>That is true. But, is it a good idea to tell how to detect a browser in
>an entry that attempts to discourage the practice of browser detecting?
I've just come across a case in which browser detecting may be
necessary.
Fetch <URL:http://www.merlyn.demon.co.uk/js-a.htm> (5kB); press the
button, and wait 0.07 minutes. At that time, presuming the longer input
field is empty, document.body.style.backgroundColor = "red" should
be executed.
In MS IE 6 and in FF 2.0.0.7, that immediately turns the background
visibly red.
In Opera 9.23, nothing visible happens until there is some other reason
to re-draw all or part of the window. Since the colour-change is what
the code is *for*, ... .
Is there a method that explicitly calls for a re-paint?
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
David Mark
> In comp.lang.javascript message <kJKdneBG6cmt0ZXaRVn_...@giganews.com>,
> Sat, 6 Oct 2007 23:02:20, FAQEditor <clj...@comcast.net> posted:
>
> >Thomas 'PointedEars' Lahn said the following on 10/6/2007 6:06 PM:
> >> Iff necessary, Opera can currently be detected by evaluating window.opera.
>
> >That is true. But, is it a good idea to tell how to detect a browser in
> >an entry that attempts to discourage the practice of browser detecting?
>
> I've just come across a case in which browser detecting may be
> necessary.
>
> Fetch <URL:http://www.merlyn.demon.co.uk/js-a.htm> (5kB); press the
> button, and wait 0.07 minutes. At that time, presuming the longer input
> field is empty, document.body.style.backgroundColor = "red" should
> be executed.
>
> In MS IE 6 and in FF 2.0.0.7, that immediately turns the background
> visibly red.
>
> In Opera 9.23, nothing visible happens until there is some other reason
> to re-draw all or part of the window. Since the colour-change is what
> the code is *for*, ... .
>
> Is there a method that explicitly calls for a re-paint?
Not really, but you are on the right track. Play around with setting
styles of other elements on the page and see if it has any effect.
Also, try the documentElement and see if it works any better. Or
change the body's class name instead of setting the inline style. One
thing that will almost surely fix it is to navigate to an anchor (put
it right above the clock interface.) Actually, that seems like a
good solution as the user may have scrolled away from the clock in the
interim.
To eliminate suspects, did you try taking the timer out of the
equation?
Try to find a safe solution that works for everything. Checking for
window.opera is the last thing you want to do. What would you do
differently if it returns an object? Assuming you can identify a
workaround that is harmful to other browsers, who is to say that older
or newer versions of Opera wouldn't be affected by it?
I have never seen this, but then I never tried to change the body's
background color on a timer. I can tell you that I have code that
switches style sheets and it affects the background color of the body
(and/or documentElement) immediately in Opera 9.
Randy Webb
> In comp.lang.javascript message <kJKdneBG6cm...@giganews.com>,
> Sat, 6 Oct 2007 23:02:20, FAQEditor <clj...@comcast.net> posted:
>> Thomas 'PointedEars' Lahn said the following on 10/6/2007 6:06 PM:
>
>
>>> Iff necessary, Opera can currently be detected by evaluating window.opera.
>> That is true. But, is it a good idea to tell how to detect a browser in
>> an entry that attempts to discourage the practice of browser detecting?
>
>
> I've just come across a case in which browser detecting may be
> necessary.
>
> Fetch <URL:http://www.merlyn.demon.co.uk/js-a.htm> (5kB); press the
> button, and wait 0.07 minutes. At that time, presuming the longer input
> field is empty, document.body.style.backgroundColor = "red" should
> be executed.
>
> In MS IE 6 and in FF 2.0.0.7, that immediately turns the background
> visibly red.
>
> In Opera 9.23, nothing visible happens until there is some other reason
> to re-draw all or part of the window. Since the colour-change is what
> the code is *for*, ... .
I tested it in Opera 9.22 and it behaved exactly as IE7 and FF2.0
behave. Turns the background yellow then turns it red. Upgrading to 9.23
gives me the same behavior where it changes it to yellow and then to red
when the counter counts down to zero.
> Is there a method that explicitly calls for a re-paint?
No. Only exiting the current execution but I can't duplicate the failure
in Opera that you describe.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Randy Webb
> On Oct 7, 5:32 pm, Dr J R Stockton <j...@merlyn.demon.co.uk> wrote:
>> In comp.lang.javascript message <kJKdneBG6cmt0ZXaRVn_...@giganews.com>,
>> Sat, 6 Oct 2007 23:02:20, FAQEditor <clj...@comcast.net> posted:
>>
>>> Thomas 'PointedEars' Lahn said the following on 10/6/2007 6:06 PM:
>>>> Iff necessary, Opera can currently be detected by evaluating window.opera.
>>> That is true. But, is it a good idea to tell how to detect a browser in
>>> an entry that attempts to discourage the practice of browser detecting?
>> I've just come across a case in which browser detecting may be
>> necessary.
>>
>> Fetch <URL:http://www.merlyn.demon.co.uk/js-a.htm> (5kB); press the
>> button, and wait 0.07 minutes. At that time, presuming the longer input
>> field is empty, document.body.style.backgroundColor = "red" should
>> be executed.
>>
>> In MS IE 6 and in FF 2.0.0.7, that immediately turns the background
>> visibly red.
>>
>> In Opera 9.23, nothing visible happens until there is some other reason
>> to re-draw all or part of the window. Since the colour-change is what
>> the code is *for*, ... .
>>
>> Is there a method that explicitly calls for a re-paint?
>
> Not really, but you are on the right track.
Can you, or have you, duplicated it in Opera9? I can't is why I ask. I
get the same behavior in IE7, FF2.0, Opera9.22 and Opera9.23
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
David Mark
> David Mark said the following on 10/7/2007 7:10 PM:
>
>
>
>
>
> > On Oct 7, 5:32 pm, Dr J R Stockton <j...@merlyn.demon.co.uk> wrote:
> >> In comp.lang.javascript message <kJKdneBG6cmt0ZXaRVn_...@giganews.com>,
> >> Sat, 6 Oct 2007 23:02:20, FAQEditor <clj...@comcast.net> posted:
>
> >>> Thomas 'PointedEars' Lahn said the following on 10/6/2007 6:06 PM:
> >>>> Iff necessary, Opera can currently be detected by evaluating window.opera.
> >>> That is true. But, is it a good idea to tell how to detect a browser in
> >>> an entry that attempts to discourage the practice of browser detecting?
> >> I've just come across a case in which browser detecting may be
> >> necessary.
>
> >> Fetch <URL:http://www.merlyn.demon.co.uk/js-a.htm> (5kB); press the
> >> button, and wait 0.07 minutes. At that time, presuming the longer input
> >> field is empty, document.body.style.backgroundColor = "red" should
> >> be executed.
>
> >> In MS IE 6 and in FF 2.0.0.7, that immediately turns the background
> >> visibly red.
>
> >> In Opera 9.23, nothing visible happens until there is some other reason
> >> to re-draw all or part of the window. Since the colour-change is what
> >> the code is *for*, ... .
>
> >> Is there a method that explicitly calls for a re-paint?
>
> > Not really, but you are on the right track.
>
> Can you, or have you, duplicated it in Opera9? I can't is why I ask. I
> get the same behavior in IE7, FF2.0, Opera9.22 and Opera9.23
>
I duplicated it in Opera 9.21 and also found a workaround. Changing
the className of the body updates the color, regardless of what you
change it to. The best solution is to define the color schemes for
the clock in CSS classes. If the colors must be hard-coded into the
script, then you can change the body class name to anything that isn't
defined in the style sheets. In testing I changed it to "test1" after
the yellow event and "test2" after the red.
Randy Webb
Makes me wonder what I might have set differently for it to work for me.
The 9.23 was a default install (I installed 9.23 just to test this with).
David Mark
It probably is not a difference in the Opera installation. A refresh
problem like that could be affected by differences in display drivers,
operating systems, etc. I'm sure the Opera software tried to repaint
the window, but for some low-level reason it didn't happen.
Windows Safari Beta has lots of issues like this. As I recall, older
versions of Netscape/Mozilla/Gecko can do this when setting
innerHTML. Typically, setting a className or the display property of
the affected element fixes it. I recall a particularly bad script
that sniffed for Gecko browsers and then set an interval to constantly
change the display property of some dummy element.
Randy Webb
Then detecting Opera won't detect the problem :-\
> A refresh problem like that could be affected by differences in display
> drivers, operating systems, etc. I'm sure the Opera software tried to
> repaint the window, but for some low-level reason it didn't happen.
That could be easy to test for, I think. Wait 3 seconds and check the
backgroundColor property and if it is red.....
David Mark
That was my original point. In the end, the solution is suitable for
all browsers, so there is no need to detect the problem at all.
>
> > A refresh problem like that could be affected by differences in display
> > drivers, operating systems, etc. I'm sure the Opera software tried to
> > repaint the window, but for some low-level reason it didn't happen.
>
> That could be easy to test for, I think. Wait 3 seconds and check the
> backgroundColor property and if it is red.....
Opera will certainly return red for the style property, regardless of
what state the window is in. The browser changed the property, but
something low-level didn't refresh the client area of the window.
Dr J R Stockton
legroups.com>, Sun, 7 Oct 2007 17:34:42, David Mark
<dmark....@gmail.com> posted:
>
>It probably is not a difference in the Opera installation. A refresh
>problem like that could be affected by differences in display drivers,
>operating systems, etc. I'm sure the Opera software tried to repaint
>the window, but for some low-level reason it didn't happen.
I got the same effect with Opera on an entirely different PC. Both are
running XP, but one is a generic desktop with a CRT and the other is an
Acer LCD laptop.
Given what one sees if one half-hides the Opera window before it fires,
and then looks, Opera is indeed painting something red (i.e. doing more
than just setting a variable or a passive property) but it's not
persuading Windows to actually show it.
A pragmatical crude workround in this case is to put anything other than
an empty string in the larger input field.
The simplest page with one button directly doing the command works in
Opera; one that wraps the command in exec(" ") does not. When
testing without a timer, one really wants a means of executing on an
already-loaded page without doing anything that rewrites anything, to be
certain that the test is sound.
But I don't absolutely need a way of getting it to work in Opera; the
page is primarily for my own use, and using IE is an adequate fix.
However, using
if (X) { window.location = X }
else { document.body.style.backgroundColor = "red"
document.body.className = "O" + Opera++ }
fixes it. There, Opera++ or similar is needed so that subsequent
firings give a different Class.
Thanks.
Now, however, in Opera only, when the background goes red most of the
form contents leap to the left, returning a second later.
Page js-a.htm is a temporary for js-alarm.htm, which is not there any
more for reasons of bandwidth (it *could* conceivably be popular); it
therefore now has code to prevent it from working when loaded from the
Web server (but a copy will work); and so that readers can currently
test it the effective part of that code, in SetJob, is commented out
/pro tem/.
But the original point, relating to the feature detection discussion
earlier in thread, is that whether or not the visible screen is actually
written is a feature undetectable by code - and, if there were no
workround acceptable to all browsers, browser detection would be
justified.
David Mark
> In comp.lang.javascript message <1191803682.585954.59...@57g2000hsv.goog> <dmark.cins...@gmail.com> posted:
>
>
>
> >It probably is not a difference in the Opera installation. A refresh
> >problem like that could be affected by differences in display drivers,
> >operating systems, etc. I'm sure the Opera software tried to repaint
> >the window, but for some low-level reason it didn't happen.
>
> I got the same effect with Opera on an entirely different PC. Both are
> running XP, but one is a generic desktop with a CRT and the other is an
> Acer LCD laptop.
I did too, but Randy didn't. Who knows what the difference is?
>
> Given what one sees if one half-hides the Opera window before it fires,
> and then looks, Opera is indeed painting something red (i.e. doing more
> than just setting a variable or a passive property) but it's not
> persuading Windows to actually show it.
Right.
>
> A pragmatical crude workround in this case is to put anything other than
> an empty string in the larger input field.
To make it redirect? That short-circuits the whole color update. I
guess that qualifies as a (very) crude workaround.
>
> The simplest page with one button directly doing the command works in
> Opera; one that wraps the command in exec(" ") does not. When
You lost me there. But I should note that neither the yellow nor the
red updates worked here (without the className updated.)
> testing without a timer, one really wants a means of executing on an
> already-loaded page without doing anything that rewrites anything, to be
> certain that the test is sound.
>
> But I don't absolutely need a way of getting it to work in Opera; the
> page is primarily for my own use, and using IE is an adequate fix.
>
> However, using
> if (X) { window.location = X }
> else { document.body.style.backgroundColor = "red"
> document.body.className = "O" + Opera++ }
> fixes it. There, Opera++ or similar is needed so that subsequent
> firings give a different Class.
In testing I set it to "test1" on the yellow update and "test2" on
red. Are you not having a problem with yellow?
>
> Thanks.
>
> Now, however, in Opera only, when the background goes red most of the
> form contents leap to the left, returning a second later.
That I didn't see. Try using the documentElement instead of the body
and see if the same thing happens.
>
> Page js-a.htm is a temporary for js-alarm.htm, which is not there any
> more for reasons of bandwidth (it *could* conceivably be popular); it
> therefore now has code to prevent it from working when loaded from the
> Web server (but a copy will work); and so that readers can currently
> test it the effective part of that code, in SetJob, is commented out
> /pro tem/.
>
> But the original point, relating to the feature detection discussion
> earlier in thread, is that whether or not the visible screen is actually
> written is a feature undetectable by code - and, if there were no
> workround acceptable to all browsers, browser detection would be
> justified.
>
If there were no universal workaround and you could be sure that an
Opera-specific workaround would not break future (or past) versions of
Opera, considering that Opera has an object to detect (as opposed to
sniffing the user agent string), then looking at window.opera wouldn't
be out of the question. The first condition is a mighty big if though
as I have never run into such a case in scripting. CSS workarounds
for IE are another story.
Dr J R Stockton
oglegroups.com>, Mon, 8 Oct 2007 16:06:41, David Mark
<dmark....@gmail.com> posted:
>On Oct 8, 4:26 pm, Dr J R Stockton <j...@merlyn.demon.co.uk> wrote:
>> In comp.lang.javascript message <1191803682.585954.59...@57g2000hsv.goog
>> legroups.com>, Sun, 7 Oct 2007 17:34:42, David Mark
>> <dmark.cins...@gmail.com> posted:
>> The simplest page with one button directly doing the command works in
>> Opera; one that wraps the command in exec(" ") does not. When
>
>You lost me there. But I should note that neither the yellow nor the
>red updates worked here (without the className updated.)
Only the red has ever failed here.
<input type=button // simplest
onClick="document.body.style.backgroundColor='red'">
<input type=button // with exec
onClick="exec(\"document.body.style.backgroundColor='red'\")">
>In testing I set it to "test1" on the yellow update and "test2" on
>red. Are you not having a problem with yellow?
No, only ever with red, which is at timeout.
>> Now, however, in Opera only, when the background goes red most of the
>> form contents leap to the left, returning a second later.
>
>That I didn't see. Try using the documentElement instead of the body
>and see if the same thing happens.
I could not get documentElement to work, on that page, in IE6; so I
didn't pursue it. The leap also occurs on pressing the button.
It works adequately now in IE6, Opera 9.23, Firefox 2.0.0.7, and
probably IE 7.
>> But the original point, relating to the feature detection discussion
>> earlier in thread, is that whether or not the visible screen is actually
>> written is a feature undetectable by code - and, if there were no
>> workround acceptable to all browsers, browser detection would be
>> justified.
>>
>
>If there were no universal workaround and you could be sure that an
>Opera-specific workaround would not break future (or past) versions of
>Opera, considering that Opera has an object to detect (as opposed to
>sniffing the user agent string), then looking at window.opera wouldn't
>be out of the question. The first condition is a mighty big if though
>as I have never run into such a case in scripting. CSS workarounds
>for IE are another story.
Too strong! One can never be quite sure what future versions might do.
But, being non-commercial, my view is that if a page of mine fails under
new circumstances, that's the user's problem until I'm told about it,
after which it's shared.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
I find MiniTrue useful for viewing/searching/altering files, at a DOS prompt;
free, DOS/Win/UNIX, <URL:http://www.idiotsdelight.net/minitrue/> unsupported.