FORM and javascript.location

I am using an asp page in which i dynamically fill the ACTION property
of the form. The problem is that whenever i try to redirect to a html
page using the javascript:location, it is getting redirected to the
location in the ACTION attribute of the form element despite what is
assigned to the location attribute of the javascript.

<FORM NAME="CRYSTFORM" METHOD=POST ACTION=<%=thisPage%>>
:
:
:

</FORM>


<button onClick ="javascript:location='<%=goBackToURL%>'";id=button1
name=button1> OK </button>


I am using div tags in middle of the form to control the visibility of
certain visual elements.

Any help would be greatly appreciated.


Thanks in advance,
John.

Evertjan
Sat Sep 09 07:02:05 CDT 2006

wrote on 09 sep 2006 in microsoft.public.inetserver.asp.general:

> I am using an asp page in which i dynamically fill the ACTION property
> of the form. The problem is that whenever i try to redirect to a html
> page using the javascript:location, it is getting redirected to the
> location in the ACTION attribute of the form element despite what is
> assigned to the location attribute of the javascript.

yes, but not as you showed, only if the button element is inside(!!!) the
form, the submit could fire first

>
> <FORM NAME="CRYSTFORM" METHOD=POST ACTION=<%=thisPage%>>

use clientside quotes for the case that there is a space in the thispage
value. use single quptes clientside for clarity.

Try:

<form name = 'crystform' method = 'post' action = '<% = thispage %>'>

> :
> :
> :
>
> </FORM>
>
>
> <button onClick ="javascript:location='<%=goBackToURL%>'";id=button1
> name=button1> OK </button>

do not use a ; outside the javascript string

onClick expects javascript [if no clientsided vbs is used],
so do not add the Javascript: part.

Try adding type='button' if inside a form.

<button type='button'
onClick ="location.href='<%=goBackToURL%>';"
id='button1'
name='button1'>
go back
</button>

> I am using div tags in middle of the form to control the visibility of
> certain visual elements.

not related to your problem, John.



--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Dave
Sat Sep 09 10:06:42 CDT 2006

johnemmatty@gmail.com wrote:
> I am using an asp page in which i dynamically fill the ACTION property
> of the form. The problem is that whenever i try to redirect to a html
> page using the javascript:location, it is getting redirected to the
> location in the ACTION attribute of the form element despite what is
> assigned to the location attribute of the javascript.
>
> <FORM NAME="CRYSTFORM" METHOD=POST ACTION=<%=thisPage%>>
>>
>>
>>
>
> </FORM>
>
>
> <button onClick ="javascript:location='<%=goBackToURL%>'";id=button1
> name=button1> OK </button>

I would start by getting out of the habit of using the javascript:
pseudo-protocol. The HTML specification requires the browser to hand the
contents of ONCLICK attributes to a scripting engine:

onclick = script [CT]
http://www.w3.org/TR/html4/interact/scripts.html#adef-onclick

...and...

User agents must not evaluate script data as HTML markup but
instead must pass it on as data to a script engine.
http://www.w3.org/TR/html4/types.html#type-script

In my opinion, if you are using the javascript: pseudo-protocol, you are
doing something wrong. More here: http://jibbering.com/faq/#FAQ4_24

But the real issue is that you did not realize that by default, the BUTTON
element is the same as an INPUT TYPE="submit":

17.5 The BUTTON element
type = submit|button|reset [CI]
This attribute declares the type of the button.
Possible values:
* submit: Creates a submit button. This is the
default value.
* reset: Creates a reset button.
* button: Creates a push button.

http://www.w3.org/TR/html4/interact/forms.html#edef-BUTTON

Solutions include:

- Use the TYPE="button" attribute
- Cancel the action of the form by preventing
the click action from propogating:
onclick="location='<%=goBackToURL%>';return false"
- Change to INPUT TYPE="button"
- Use an anchor: <a href="<%=goBackToURL%>">


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

johnemmatty
Sun Sep 10 23:59:04 CDT 2006

Thanks to everyone replied to my query... especially to Evertjan, your
post helped me to solve my problem. Dave Anderson.. your post was
resourceful and served me to acquire new informations,and i really
really liked your signature.

Thanks,
John.
Dave Anderson wrote:
> johnemmatty@gmail.com wrote:
> > I am using an asp page in which i dynamically fill the ACTION property
> > of the form. The problem is that whenever i try to redirect to a html
> > page using the javascript:location, it is getting redirected to the
> > location in the ACTION attribute of the form element despite what is
> > assigned to the location attribute of the javascript.
> >
> > <FORM NAME="CRYSTFORM" METHOD=POST ACTION=<%=thisPage%>>
> >>
> >>
> >>
> >
> > </FORM>
> >
> >
> > <button onClick ="javascript:location='<%=goBackToURL%>'";id=button1
> > name=button1> OK </button>
>
> I would start by getting out of the habit of using the javascript:
> pseudo-protocol. The HTML specification requires the browser to hand the
> contents of ONCLICK attributes to a scripting engine:
>
> onclick = script [CT]
> http://www.w3.org/TR/html4/interact/scripts.html#adef-onclick
>
> ...and...
>
> User agents must not evaluate script data as HTML markup but
> instead must pass it on as data to a script engine.
> http://www.w3.org/TR/html4/types.html#type-script
>
> In my opinion, if you are using the javascript: pseudo-protocol, you are
> doing something wrong. More here: http://jibbering.com/faq/#FAQ4_24
>
> But the real issue is that you did not realize that by default, the BUTTON
> element is the same as an INPUT TYPE="submit":
>
> 17.5 The BUTTON element
> type = submit|button|reset [CI]
> This attribute declares the type of the button.
> Possible values:
> * submit: Creates a submit button. This is the
> default value.
> * reset: Creates a reset button.
> * button: Creates a push button.
>
> http://www.w3.org/TR/html4/interact/forms.html#edef-BUTTON
>
> Solutions include:
>
> - Use the TYPE="button" attribute
> - Cancel the action of the form by preventing
> the click action from propogating:
> onclick="location='<%=goBackToURL%>';return false"
> - Change to INPUT TYPE="button"
> - Use an anchor: <a href="<%=goBackToURL%>">
>
>
> --
> Dave Anderson
>
> Unsolicited commercial email will be read at a cost of $500 per message. Use
> of this email address implies consent to these terms.

Dave
Mon Sep 11 11:25:16 CDT 2006

Evertjan. wrote:
> use clientside quotes for the case that there is a space
> in the thispage value. use single quptes clientside for
> clarity.
>
> <form name = 'crystform' method = 'post' action = '<% = thispage %>'>

And if the value contains single quotes, Evertjan?

I think this is poor advice. Double quotes plus Server.HTMLEncode() is the
proper way to inject data into attributes:

<form action="<%=Server.HTMLEncode(thispage)%>" ...>

I also think your argument for clarity lacks merit, but that is a matter of
taste, I suppose.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

Evertjan
Mon Sep 11 12:26:39 CDT 2006

Dave Anderson wrote on 11 sep 2006 in
microsoft.public.inetserver.asp.general:

> Evertjan. wrote:
>> use clientside quotes for the case that there is a space
>> in the thispage value. use single quptes clientside for
>> clarity.
>>
>> <form name = 'crystform' method = 'post' action = '<% = thispage %>'>
>
> And if the value contains single quotes, Evertjan?
>
> I think this is poor advice. Double quotes plus Server.HTMLEncode() is
> the proper way to inject data into attributes:
>
> <form action="<%=Server.HTMLEncode(thispage)%>" ...>

Wouldn't that encode single quote/apostophe just as well?

> I also think your argument for clarity lacks merit, but that is a
> matter of taste, I suppose.

I always, well if possible, enclose clientside strings in single quotes in
a mixed, that is clientside and serverside code, environment.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Dave
Mon Sep 11 12:39:18 CDT 2006

Evertjan. wrote:
>> <form action="<%=Server.HTMLEncode(thispage)%>" ...>
>
> Wouldn't that encode single quote/apostophe just as well?

You should already know that it does not. What would it encode to? There is
a character entity defined for double quote (&quot;). There is not one for
apostrophe.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

Evertjan
Mon Sep 11 12:52:39 CDT 2006

Dave Anderson wrote on 11 sep 2006 in
microsoft.public.inetserver.asp.general:

> Evertjan. wrote:
>>> <form action="<%=Server.HTMLEncode(thispage)%>" ...>
>>
>> Wouldn't that encode single quote/apostophe just as well?
>
> You should already know that it does not. What would it encode to?
> There is a character entity defined for double quote (&quot;). There
> is not one for apostrophe.

Why do you expect things of me?

I never use[d] Server.HTMLEncode().

I never put any quotes in an URL,
and try not to have spaces in them, but that happens now and again.
I don't write <form>s to external URLs, only to my own,
and I master my own URL naming.


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Dave
Mon Sep 11 13:53:08 CDT 2006

Evertjan. wrote:
> Why do you expect things of me?

Because you offer advice.



> I never use[d] Server.HTMLEncode().

That's a shame. Most of my forms post back to themselves, which leads to the
inevitable:

<input name="xxx" value="<%=xxx%>">

...where xxx is Server.HTMLEncode(Request.Form("xxx").Item).

Without HTMLEncode, how do you deal with arbitrary markup, Evertjan? Do you
really want to inject a value like ["><input name="yyy" ...>< "] into your
document?



> I never put any quotes in an URL, and try not to have
> spaces in them, but that happens now and again.
> I don't write <form>s to external URLs, only to my own,
> and I master my own URL naming.

This is not about URLs. My comments are directed at your "use single quotes"
advice. Filling an HTML attribute with arbitrary data is among the various
reasons why that advice is anti-useful.



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

johnemmatty
Tue Sep 12 02:02:13 CDT 2006

The problem is back..........in mozilla firefox 1.7.12..HA..HA. It was
ok with 1.5.0.6.


Dave Anderson wrote:
> Evertjan. wrote:
> > Why do you expect things of me?
>
> Because you offer advice.
>
>
>
> > I never use[d] Server.HTMLEncode().
>
> That's a shame. Most of my forms post back to themselves, which leads to the
> inevitable:
>
> <input name="xxx" value="<%=xxx%>">
>
> ...where xxx is Server.HTMLEncode(Request.Form("xxx").Item).
>
> Without HTMLEncode, how do you deal with arbitrary markup, Evertjan? Do you
> really want to inject a value like ["><input name="yyy" ...>< "] into your
> document?
>
>
>
> > I never put any quotes in an URL, and try not to have
> > spaces in them, but that happens now and again.
> > I don't write <form>s to external URLs, only to my own,
> > and I master my own URL naming.
>
> This is not about URLs. My comments are directed at your "use single quotes"
> advice. Filling an HTML attribute with arbitrary data is among the various
> reasons why that advice is anti-useful.
>
>
>
> --
> Dave Anderson
>
> Unsolicited commercial email will be read at a cost of $500 per message. Use
> of this email address implies consent to these terms.

Evertjan
Tue Sep 12 02:19:52 CDT 2006

Dave Anderson wrote on 11 sep 2006 in
microsoft.public.inetserver.asp.general:

> Evertjan. wrote:
>> Why do you expect things of me?
>
> Because you offer advice.
>
>> I never use[d] Server.HTMLEncode().
>
> That's a shame. Most of my forms post back to themselves, which leads
> to the inevitable:
>
> <input name="xxx" value="<%=xxx%>">

That is different, I thought we were talking

<form action=...

so about url's

> ...where xxx is Server.HTMLEncode(Request.Form("xxx").Item).
>
> Without HTMLEncode, how do you deal with arbitrary markup, Evertjan?
> Do you really want to inject a value like ["><input name="yyy" ...><
> "] into your document?

I never deal with arbitrary strings [why do you call it markup?]

I always validate to my liking, which often involves preparing for database
input

>> I never put any quotes in an URL, and try not to have
>> spaces in them, but that happens now and again.
>> I don't write <form>s to external URLs, only to my own,
>> and I master my own URL naming.
>
> This is not about URLs. My comments are directed at your "use single
> quotes" advice. Filling an HTML attribute with arbitrary data is among
> the various reasons why that advice is anti-useful.

I stand by the my of single quites in always html and in javascript
whenever not impractical.

I never allow arbitrary data, and I would suggest to anyone not to do that.
Input data should be tested and either converted or rejected at the start,
which is IMHO a reasonable burden to the user.

I think the use of Server.HTMLEncode() is a nice way, but if it does not
convert the apostrofe, not a good one for my standards.

The use of &quot; and %24,etc are a nucance anyway, because they alter the
length of a string, and get you into unforseen behavour with string
manipulation, be it old and trusted mid() or regex.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Dave
Tue Sep 12 07:44:24 CDT 2006

[please do not toppost]

johnemmatty@gmail.com wrote:
> The problem is back..........in mozilla firefox 1.7.12..HA..HA.
> It was ok with 1.5.0.6.

What on earth are you talking about?



--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

Dave
Tue Sep 12 08:05:55 CDT 2006

Evertjan. wrote:
>> Without HTMLEncode, how do you deal with arbitrary markup,
>> Evertjan? Do you really want to inject a value like
> ["><input name="yyy" ...>< > "] into your document?
>
> I never deal with arbitrary strings [why do you call it markup?]

If you use text inputs or textareas, you deal with arbitrary strings.

Why do I call markup submitted as input values markup? Gee, I don't know...



> I never allow arbitrary data, and I would suggest to anyone
> not to do that. Input data should be tested and either
> converted or rejected at the start, which is IMHO a
> reasonable burden to the user.

I always allow free-form data in textareas, since I cannot rule out the
legitimate need for a specific character. There is *nothing* difficult about
it.



> I think the use of Server.HTMLEncode() is a nice way, but
> if it does not convert the apostrofe, not a good one for my
> standards.

You do realize that this makes my point for me, don't you?



> The use of &quot; and %24,etc are a nucance anyway, because
> they alter the length of a string, and get you into unforseen
> behavour with string manipulation, be it old and trusted
> mid() or regex.

This is ridiculous, so let me ridicule it:

(1) %24 does not result from Server.HTMLEncode(). It is
not a character entity. You could confirm this easily:
Response.Write("%24") // output: %24

(2) The browser does not care about the string length. Or
were you under the mistaken impression that I was
advocating the use of HTMLEncode for anything other
than injection into the Response stream? I don't know
where you could have gotten that idea, since all of my
examples used it properly.

(3) Mid() and RegEx are more work for you and no less work
for the server than HTMLEncode(), and they do not
preserve the user input. That's really a sad approach
to take.


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.

Evertjan
Tue Sep 12 08:13:10 CDT 2006

Dave Anderson wrote on 12 sep 2006 in
microsoft.public.inetserver.asp.general:

> Evertjan. wrote:
>>> Without HTMLEncode, how do you deal with arbitrary markup,
>>> Evertjan? Do you really want to inject a value like
>> ["><input name="yyy" ...>< > "] into your document?
>>
>> I never deal with arbitrary strings [why do you call it markup?]
>
> If you use text inputs or textareas, you deal with arbitrary strings.
>
> Why do I call markup submitted as input values markup? Gee, I don't
> know...
>
>
>
>> I never allow arbitrary data, and I would suggest to anyone
>> not to do that. Input data should be tested and either
>> converted or rejected at the start, which is IMHO a
>> reasonable burden to the user.
>
> I always allow free-form data in textareas, since I cannot rule out
> the legitimate need for a specific character. There is *nothing*
> difficult about it.
>
>
>
>> I think the use of Server.HTMLEncode() is a nice way, but
>> if it does not convert the apostrofe, not a good one for my
>> standards.
>
> You do realize that this makes my point for me, don't you?
>
>
>
>> The use of &quot; and %24,etc are a nucance anyway, because
>> they alter the length of a string, and get you into unforseen
>> behavour with string manipulation, be it old and trusted
>> mid() or regex.
>
> This is ridiculous, so let me ridicule it:
>
> (1) %24 does not result from Server.HTMLEncode(). It is
> not a character entity. You could confirm this easily:
> Response.Write("%24") // output: %24
>
> (2) The browser does not care about the string length. Or
> were you under the mistaken impression that I was
> advocating the use of HTMLEncode for anything other
> than injection into the Response stream? I don't know
> where you could have gotten that idea, since all of my
> examples used it properly.
>
> (3) Mid() and RegEx are more work for you and no less work
> for the server than HTMLEncode(), and they do not
> preserve the user input. That's really a sad approach
> to take.

As you seem intent to prove your point, not that your idea is better,
which I think is acceptable, but to use totally irrelevant comments on my
words, will stop responding.


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)