Javascript / Client Side Development :: JavaScript confirmation dialog


	JavaScript confirmation dialog Hello, I tried to use "javascript:return confirm();" function in following manner ( triggered by form onSubmit event ): <form method="post" action="mail.php" onSubmit="javascript:return confirm('Do you really want to send this order ?);"> When I include Submit button in this form form action should be performed after "OK" is clicked on confirmation dialog e.g. "mail.php" should be then executed. Only thing is that it is executed directly without any confirm windows. JS is enabled and browser is Firefox 2.0. What is more I frequently use JS in my designs and this very site I am working on now has plenty of JS included. That is a bit confusing - that code above does not work. Did I miss something when I incorporated JS in form ? Thanks, Tomislav On May 21, 3:44 pm, Tomislav <josip_mill@yahoo.com> wrote: > I tried to use "javascript:return confirm();" function in following > manner ( triggered by form onSubmit event ): > > <form method="post" action="mail.php" onSubmit="javascript:return > confirm('Do you really want to send this order ?);"> > See my P.S. comment at http://groups.google.com/group/comp.lang.javascript/msg/06f9475caf8ee778 While IE tolerates javascript: pseudo-protocol misuse, many other UAs do not. - Hide quoted text - Tomislav <josip_mill@yahoo.com> wrote: > I tried to use "javascript:return confirm();" function in following > manner ( triggered by form onSubmit event ): > ><form method="post" action="mail.php" onSubmit="javascript:return > confirm('Do you really want to send this order ?);"> > > When I include Submit button in this form form action should be > performed after "OK" is clicked on confirmation dialog e.g. "mail.php" > should be then executed. Only thing is that it is executed directly > without any confirm windows. > JS is enabled and browser is Firefox 2.0. Turn on the error console and it will tell you why that didn't work. Or even better install Firebug and you'll get a nice red error indication in the status bar which you can click to show the offending line. Your problem is that you have a missing quote mark at the end of the parameter to confirm(). You also have a completely spurious label: onsubmit doesn't take a URL: that 'javascript:' is a label not a protocol. Assuming you didn't intend to add a 'goto javascript' anywhere in your code you should delete it. - Hide quoted text - VK <schools_r@yahoo.com> wrote: > On May 21, 3:44 pm, Tomislav <josip_mill@yahoo.com> wrote: >> I tried to use "javascript:return confirm();" function in following >> manner ( triggered by form onSubmit event ): >> >> <form method="post" action="mail.php" onSubmit="javascript:return >> confirm('Do you really want to send this order ?);"> >> > See my P.S. comment at > http://groups.google.com/group/comp.lang.javascript/msg/06f9475caf8ee778 > While IE tolerates javascript: pseudo-protocol misuse, many other UAs > do not. It isn't a protocol, it's a label. Spurious but mostly harmless. Can you name any javascript implementations which wouldn't accept the label? By definition they will be broken implementations. On May 21, 5:21 pm, Duncan Booth <duncan.bo@invalid.invalid> wrote: > It isn't a protocol, it's a label. Spurious but mostly harmless. I am taking my hat off over such creative interpretation. Really, all these years I never thought of onclick="javascript:something()" as of a Javascript label in front of a statement. I guess such view was always shadowed by the usage in links like href="javascript:something()". - I hope there is no doubts that in the latter case it is pseudo-protocol? However cool such interpretation would be (and it is cool) in the original Microsoft proposal - who is the inventor of this syntax - it is spelled as "place javascript: before your JScript code" so "javascript:" part is clearly excluded from the code itself - at least in mind of authors of the proposal. I remind that it is one of ways Microsoft suggested to use for mixed pages where both VBScript and JScript are used. If the first script block on the page is VBScript then all consecutive script blocks w/o explicit type or language declaration _and_ all intrinsic event handlers on the page will be parsed using VBScript engine. Naturally if they are written in JScript the whole page will get broken. The simplest way would be of course to support meta tag Script-Content-Type but it would be too easy for such big corporation :-) So they suggested a few alternate solutions for the developers: 1) If intrinsic event handlers are written in JScript then: a) ensure that the very first script block on the page is JScript, one may simply place bogus block before anything else: <script type="text/javascript"></script> b) ensure that all consecutive script blocks have type or language declaration: or at least all blocks using VBScript 2) If the page is a holly mix of VBScript and JScript coding including intrinsic event handlers - but with VBScript as the default one - then place a marker in intrinsic event handlers like onclick="javascript:mycode()" Respectively they instructed the engine to treat that javascript: as a marker "JScript code further follows" which is obviously out of any connection with Javascript labels. I can tell that IE7 is much smarter than IE4-6 with its code type detection. Alas I also can tell that javascript: "prefix" in event handlers had time to become another classical Cargo Cult phenomenon. VK said: - Hide quoted text - >On May 21, 5:21 pm, Duncan Booth <duncan.bo@invalid.invalid> wrote: >> It isn't a protocol, it's a label. Spurious but mostly harmless. >I am taking my hat off over such creative interpretation. Really, all >these years I never thought of onclick="javascript:something()" as of >a Javascript label in front of a statement. I guess such view was >always shadowed by the usage in links like >href="javascript:something()". - I hope there is no doubts that in the >latter case it is pseudo-protocol? >However cool such interpretation would be (and it is cool) in the >original Microsoft proposal - who is the inventor of this syntax - it >is spelled as "place javascript: before your JScript code" so >"javascript:" part is clearly excluded from the code itself - at least >in mind of authors of the proposal. Microsoft took advantage of the existing label syntax to give special meanings to certain label values. This had the advantage that any browser that didn't interpret their meaning would simply ignore it as a valid (albeit useless) label. onclick="userAbort:self.close()" is also valid, of course. --