Find out if Javascript is enabled

[Alex Molochnikov]

Is there any way to find out programmatically if Javascript is
supported/enabled in a browser? By "programmatically" I mean on the Java
servlet side.

TIA

Alex Molochnikov
Gestalt Corporation

 

[Mark Preston]

Is there any way to find out programmatically if Javascript is
supported/enabled in a browser? By "programmatically" I mean on the Java
servlet side.

TIA

Alex Molochnikov
Gestalt Corporation

Java has nothing to do with Javascript, so consider this:- On your own
PC, could you run an Algol program to find out if ADA was working?
Course not.

 

[Alex Molochnikov]

Mark,

Java has nothing to do with Javascript

I lost count how many times I gave this very advice to the newbies who
mistakenly wandered into Java NGs and asked questions about Javascript. But
the question was about Java servlets _discovering_ the status of Javascript.

Java servlets are capable of determining if cookies are enabled on the
client's browser. The browser is also capable of sending a parameterized
request to the servlet, passing any info. In fact, if my question was about
discovering something _other_ than Javascript, I would have used Javascript
to get the info and pass it to the servlet. Unfortunately, in this
particular case, I cannot do so for the obvious reason.

On your own PC, could you run an Algol program to find out if ADA was working?
Course not.

The question was not about Javascript "working". It was about the Javascript
option being enabled or disabled in the _browser_, and the Java servlet
finding it out.

Perhaps, your answer should have been: "I don't know", but then you could
have simply ignored the post.

AM

 

[Alex Molochnikov]

Perhaps, your answer should have been: "I don't know", but then you could
have simply ignored the post.

And here is the answer:

<noscript>
<META HTTP-EQUIV="Refresh" CONTENT="0;
URL=Callback?JAVASCRIPTSTATUS=NONE">
</noscript>

"Callback" is the name of the servlet. Its doGet() method gets called when
the page loads and executes the <noscript> tag. The JAVASCRIPTSTATUS
parameter carries the value ("NONE") to the servlet.

My sincere thanks to everyone who looked at my inquiry, even though nobody
responded with a constructive answer.

AM

 

[Richard Cornford]

And here is the answer:

<noscript>
<META HTTP-EQUIV="Refresh" CONTENT="0;
URL=Callback?JAVASCRIPTSTATUS=NONE">
</noscript>

<snip>

This testing strategy does not answer your stated question. It may give
an indication that a client has scripting disabled/unavailable, but only
when that client also supports, and acts upon, <META
HTTP-EQUIV="Refresh" ... . As many modern browsers allow META refresh to
be disabled independently of (but obviously in addition to) javascript
the strategy risks giving an indication that scripting is enabled on the
client when in fact it is not. Generally erring in that direction should
be less desirable than erroneously assuming scripting is disabled when
in fact it is available.

However, the formal rules of HTML categorise META elements as
"head.misc" and makes the only valid location for such an element a
direct child of the HEAD element, while NOSCRIPT elements are "block"
elements and may only be descendants of the BODY element. Thus in valid
HTML a META element cannot be a child of a NOSCRIPT element. The two are
only allowed in mutually exclusive contexts. As a result this code will
also potentially give a false indication of client-side script support
on browsers that take a more literal interpretation of HTML, or apply
realistic error-correction rules.

It is always a bit depressing to be reminded of the actual number of
individuals working in the production of HTML who have little or no
technical understanding of HTML.

With the NOSCRIPT element in its correct context within the BODY it
should still be possible to make a GET request to a servlet. Placing an
IMG element, or an IFRAME element within the NOSCRIPT element would
result in valid HTML and encourage the browser to make the desired GET
request. But again, false indications of client-side script support
would be generated by browsers with images turned off, or incapable of
supporting IFRAMEs.

My sincere thanks to everyone who looked at my inquiry,
even though nobody responded with a constructive answer.

According to my newsreader you have allowed less than 13 hours for a
reply. On an international group it takes 24 hours for all of the
contributors to even see the original massage, let alone respond. But it
is quite likely that you haven't received any "constructive" responses
before now because everyone knows that there is no 100% reliable method
of acquiring the information that you have stated that you want, and the
chances are extremely slim that the information you claim to want is
actually the information you need. Though with little browser scripting
experience it is unlikely that you will see that, even if someone took
the time to explain why.

Richard.

 

[Alex Molochnikov]

It is always a bit depressing to be reminded of the actual number of
individuals working in the production of HTML who have little or no
technical understanding of HTML. [...]
But it
is quite likely that you haven't received any "constructive" responses
before now because everyone knows that there is no 100% reliable method
of acquiring the information that you have stated that you want, and the
chances are extremely slim that the information you claim to want is
actually the information you need.

Your response to my post, with the given explanations, would have been a lot
more productive, if you did not adopt the condescending tone, bordering on
insult. Making assumptions about how much I understand of my own needs is
arrogant, to put it mildly. Your other assumption about the desire for "100%
reliability" is not supported by my original post. I have been programming
since 1975, do it for the living, and do not need to be lectured about the
lack of 100% reliable solutions. And what I am working on is not a
"production HTML" at all - this is another one of your baseless assumptions.

Though with little browser scripting
experience it is unlikely that you will see that, even if someone took
the time to explain why.

Nevertheless, you attempted to do just that - I wonder, if you were tempted
by an opportunity to show off your superior knowledge of the subject, or did
it for the pleasure of putting me down.

I have been in this business long enough to know that all software products
are compromises, never reaching the originally stated goal, yet delivering
working solutions to the users. And through the years of hands-on
experience, I also learned that there is no such thing as "no solution". The
only impediment to finding the solution is the constraints of someone's
mind.

I do not expect an apology from you, nor do I need one. It will suffice if
you simply stay away from this thread, letting other people answer my
question, without insulting me.

AM

 

[Mark Preston]

And here is the answer:

<noscript>
<META HTTP-EQUIV="Refresh" CONTENT="0;
URL=Callback?JAVASCRIPTSTATUS=NONE">
</noscript>

"Callback" is the name of the servlet. Its doGet() method gets called when
the page loads and executes the <noscript> tag. The JAVASCRIPTSTATUS
parameter carries the value ("NONE") to the servlet.

My sincere thanks to everyone who looked at my inquiry, even though nobody
responded with a constructive answer.

That is certainly a means of informing the Java servelet of the current
Javascript capability of the browser (provided the browser supports the
<META> option, of course). However, it is actually the *reverse* of what
you asked for.

Here, you are using the browser to tell the Java what it can do. What
you asked for was for the Java to find the browser and work out for
itself what it could do. It may be that I misunderstood your question
with its stress on working on the servelet-side, but here you are
clearly doing the work on the client-side.

It may have been better for the question to be a bit more expressive so
that such confusion could be avoided.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Tue, 25
Jan 2005 13:49:18, seen in Mark Preston

Java has nothing to do with Javascript, so consider this:- On your own
PC, could you run an Algol program to find out if ADA was working?
Course not.

Please trim sigs.

I have no Algol here; but I can run a Pascal program to determine
whether Delphi is working (with the relationship between the languages
being inconsequential). Pascal writes a simple Delphi program
begin Writeln(1*2*3*4*5*6*7*8*9) end.
to file, uses Exec to compile it with DCC32 -cc <file> and then to
run it; and then does screen capture to look for "362880" or "Bad
command or file name". Or Delphi could write to file.


A browser could use VBScript to set a variable, then javascript to
change it, then VBscript to read it. If javascript was not enabled,
human intervention would be needed.


The usual way is to have the entry page use javascript to jump to
another page; if you get there, it worked. The calling page can set a
parameter, such as new Date().getTime(), and the destination can check
for approximate correctness, as a moderate defence against direct entry
to the second page; the parameter can be obfuscated.

 

[Alex Molochnikov]

That is certainly a means of informing the Java servelet of the current
Javascript capability of the browser (provided the browser supports the
<META> option, of course).

I tested this under IE6, NN7, Firefox and Mozilla (Linux). It works.
Collectively, these 4 browsers make up 93% of the today's market, so I am
not going to worry about the rest.

It may have been better for the question to be a bit more expressive so
that such confusion could be avoided.

Possibly so. It was clear in my mind when I wrote it, that I wanted to get
the info from the browser and pass it to the servlet. After re-reading my
post, I see that it could be interpreted as getting the info on the servlet
side, without any involvement of the browser.

Anyway, thank you for the comments. I will try to spell things out in more
detail when I post again.

Regards,

Alex.

 

[Randy Webb]

I tested this under IE6, NN7, Firefox and Mozilla (Linux). It works.
Collectively, these 4 browsers make up 93% of the today's market, so I am
not going to worry about the rest.

Open IE6
Tools>Internet Options>Security Tab>Advanced Options.
Scroll down to the Miscellaneous Section.
Second option is to Enable/Disable META REFRESH.

Meta Refresh is just as simple to disable in IE as script is.

 

[Randy Webb]

JRS: In article <[email protected]>, dated Tue, 25
Jan 2005 13:49:18, seen in Mark Preston

A browser could use VBScript to set a variable, then javascript to
change it, then VBscript to read it. If javascript was not enabled,
human intervention would be needed.

If javascript was not enabled, then VBScript is also disabled. IE
doesn't distinguish between VB or J Script, only "Scripting". Also, the
scenario you describe would fail in any non-IE browser since it wouldn't
support VBScript but may indeed have Scripting enabled.

<--snip-->


--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

 

[Alex Molochnikov]

The usual way is to have the entry page use javascript to jump to
another page; if you get there, it worked. The calling page can set a
parameter, such as new Date().getTime(), and the destination can check
for approximate correctness, as a moderate defence against direct entry
to the second page; the parameter can be obfuscated.

This is pretty much what I have done, as I posted already in this thread,
except that the jump is triggered by the _absense_ of Javascript, and the
invoked resource is not a page, but a Java servlet.

I considered a direct approach advocated by you, with Javascript calling on
the servlet, but since my primary concern is detecting the exception (which,
for our application, the absense of Javascript would be), I felt that it is
more efficient to default the status to "Javascript ON", and trigger the
action from the <NOSCRIPT> block if the Javascript is disabled.

Thank you for your help.

Alex.

 

[Alex Molochnikov]

Meta Refresh is just as simple to disable in IE as script is.

That may be so, but my concern was if META refresh is supported as a
feature, regardless of its status in the browser settings. And as far I can
tell, it is enabled by default. I can see why the users might want to turn
off the Javascript as a possible security risk, but why would they disable
the META refresh?

Alex.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Wed, 26 Jan
2005 18:03:07, seen in Randy Webb

If javascript was not enabled, then VBScript is also disabled. IE
doesn't distinguish between VB or J Script, only "Scripting". Also, the
scenario you describe would fail in any non-IE browser since it wouldn't
support VBScript but may indeed have Scripting enabled.

What I wrote is perfectly compatible with that. A browser writer could
choose to allow the two to be enabled independently.

VBScript can detect whether javascript is enabled; it is just that you
don't know of any circumstances in which it would run and return other
than "Yes". IIRC, in IE javascript is actually implemented by a
separate component, so that it is technically possible to upgrade
"MSIE's javascript" without upgrading "MSIE proper" - so one could in
principle replace the javascript component itself with a non-functional
substitute.

There's no reason why a non-IE browser should not support VBScript,
either; but in a browser that does not support VBScript, one cannot
expect VBScript to detect anything.

Remember, I was only giving examples of how one language can detect
another.

Alex - if triggering in <noscript>, remember that <noscript> can be
executed if a previous <script> failed - though probably that does not
matter for you.