onClick="windows.location..." Fails after IE 6 Security Update onW/ME?

[Roger]

Hi,

I have been using this trick for some time on a home page. The idea is
to verify the user's browser has Javascript enabled before allowing the
user to access a logon page. The NoJavascript.html page has instructions
for turning on Javascript.

<a href="/NoJavascript.html"
onclick="window.location='/Logon';return false;">Logon </a>

A Windows/ME PC using IE 6 now consistently goes to the
NoJavaScript.html page when the button is clicked even though Javascript
is enabled.

This has been working for several months and continues to work with IE 6
on Windows/XP and other browsers such as Firefox, Opera, etc.

I think the problem is related to the W/ME PC installing the IE 6
Cumulative security Update SP1 (KB896727). Has anyone else encountered a
similar problem and found a solution?

Roger

[Mick White]

Roger wrote:

Hi,

I have been using this trick for some time on a home page. The idea is
to verify the user's browser has Javascript enabled before allowing the
user to access a logon page. The NoJavascript.html page has instructions
for turning on Javascript.

<a href="/NoJavascript.html" onclick="window.location='/Logon';return
false;">Logon </a>

A Windows/ME PC using IE 6 now consistently goes to the
NoJavaScript.html page when the button is clicked even though Javascript
is enabled.
Does this only fail locally?
Mick

This has been working for several months and continues to work with IE 6
on Windows/XP and other browsers such as Firefox, Opera, etc.

I think the problem is related to the W/ME PC installing the IE 6
Cumulative security Update SP1 (KB896727). Has anyone else encountered a
similar problem and found a solution?

Roger

[Csaba Gabor]

Sometimes it's nice to know whether a user's browser supports cookies
and whether they have javascript enabled, even if just to gather
statistics.

For the former, upon the initial request and no indication that the
client is a former visitor, you can send back a cookie with the
response from the server, which response is simply a "server has moved"
directing the browser back to a shill page on your server, which apache
picks up and then redirects back to the original (only by now you know
what the cookie situation is so you don't need to do any more monkey
business).

It means that new users and those without cookies need to suffer
through 2 redirects (so they can wind up at a page that looks like what
they clicked on or typed into the browser's address bar). Really, it
is much classier if you can do a single redirect to the same page.
This is trickier, though, because how do you differentiate between a
first hit and redirected browser hit for browsers without cookies.
Something to think about.

Frankly, this cookie stuff is overblown from my point of view. If
they're returning and have cookies, you obviously know (as the server).
If not, does it really gain you anything to do that redirection to
determine cookie capability - I'm thinking no, unless you're desparate
for statistics. If the visitor hasn't made a single click on your
site, chances are your knowing about cookies is not going to make any
difference.

Anyway, you were interested in javascript. Now as far as that goes, If
I remember correctly, you could not do an onLoad="preempt redirection
by self submitting, thus determining js status" because the redirection
takes priority. However, since you are not interested in redirections
when js is missing, it should work for you (at least on my IE 6) is
that you can have a mini nothing form, and then have an
onload="document.forms[0].submit()". And since you'll use a POST
method, the user will never see address bar changes.

Good luck,
Csaba Gabor from Vienna

[Csaba Gabor]

Sometimes it's nice to know whether a user's browser supports cookies
and whether they have javascript enabled, even if just to gather
statistics.

For the former, upon the initial request and no indication that the
client is a former visitor, you can send back a cookie with the
response from the server, which response is simply a "server has moved"
directing the browser back to a shill page on your server, which apache
picks up and then redirects back to the original (only by now you know
what the cookie situation is so you don't need to do any more monkey
business).

It means that new users and those without cookies need to suffer
through 2 redirects (so they can wind up at a page that looks like what
they clicked on or typed into the browser's address bar). Really, it
is much classier if you can do a single redirect to the same page.
This is trickier, though, because how do you differentiate between a
first hit and redirected browser hit for browsers without cookies.
Something to think about.

Frankly, this cookie stuff is overblown from my point of view. If
they're returning and have cookies, you obviously know (as the server).
If not, does it really gain you anything to do that redirection to
determine cookie capability - I'm thinking no, unless you're desparate
for statistics. If the visitor hasn't made a single click on your site,
chances are your knowing about cookies is not going to make any
difference.

Anyway, you were interested in javascript. Now as far as that goes, if
I remember correctly, you could not do an onLoad="preempt redirection
by self submitting, thus determining js status" because the redirection
takes priority. However, since you are not interested in redirections
when js is missing, it should work for you (at least on my IE 6). You
can have a mini nothing form, and have an
onload="document.forms[0].submit()". And since you'll use a POST
method, the user will never see address bar changes.

Good luck,
Csaba Gabor from Vienna

[Roger]

Mick White wrote:

Roger wrote:

Hi,

I have been using this trick for some time on a home page. The idea is
to verify the user's browser has Javascript enabled before allowing
the user to access a logon page. The NoJavascript.html page has
instructions for turning on Javascript.

<a href="/NoJavascript.html"
onclick="window.location='/Logon';return false;">Logon </a>

A Windows/ME PC using IE 6 now consistently goes to the
NoJavaScript.html page when the button is clicked even though
Javascript is enabled.

Does this only fail locally?
Mick

On a local LAN -- the production application is running on Redhat Fedora
Core 3 Apache. A test version of the application runs on W/XP with
Apache. Accessing either application now results in the same failure.

Roger

This has been working for several months and continues to work with IE
6 on Windows/XP and other browsers such as Firefox, Opera, etc.

I think the problem is related to the W/ME PC installing the IE 6
Cumulative security Update SP1 (KB896727). Has anyone else encountered
a similar problem and found a solution?

Roger