Find out if Javascript is enabled

[Alex Molochnikov]

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

TIA

Alex Molochnikov
Gestalt Corporation

[Mark Preston]

Alex Molochnikov wrote:

Is there any way to find out programmaticall y if Javascript is
supported/enabled in a browser? By "programmatical ly" 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]

"Alex Molochnikov" <NO****@NOSPAM. COM> wrote in message
news:wiuJd.1694 82$Xk.89165@pd7 tw3no...

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?JA VASCRIPTSTATUS= NONE">
</noscript>

"Callback" is the name of the servlet. Its doGet() method gets called when
the page loads and executes the <noscript> tag. The JAVASCRIPTSTATU S
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]

Alex Molochnikov wrote:

Alex Molochnikov wrote:

Perhaps, your answer should have been: "I don't know", ...

<snip> And here is the answer:

<noscript>
<META HTTP-EQUIV="Refresh" CONTENT="0;
URL=Callback?JA VASCRIPTSTATUS= 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 "constructi ve" 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]

"Richard Cornford" <Ri*****@litote s.demon.co.uk> wrote in message
news:ct******** ***********@new s.demon.co.uk.. .

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 "constructi ve" 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]

Alex Molochnikov wrote:

"Alex Molochnikov" <NO****@NOSPAM. COM> wrote in message
news:wiuJd.1694 82$Xk.89165@pd7 tw3no...

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?JA VASCRIPTSTATUS= NONE">
</noscript>

"Callback" is the name of the servlet. Its doGet() method gets called when
the page loads and executes the <noscript> tag. The JAVASCRIPTSTATU S
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.

[Alex Molochnikov]

"Mark Preston" <us****@nosourc e.co.uk> wrote in message
news:ct******** ***********@new s.demon.co.uk.. .

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.

[Dr John Stockton]

JRS: In article <ct************ *******@news.de mon.co.uk>, dated Tue, 25
Jan 2005 13:49:18, seen in news:comp.lang. javascript, Mark Preston
<us****@nosourc e.co.uk> posted :

Alex Molochnikov wrote:

Is there any way to find out programmaticall y if Javascript is
supported/enabled in a browser? By "programmatical ly" 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.

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.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Randy Webb]

Alex Molochnikov wrote:

"Mark Preston" <us****@nosourc e.co.uk> wrote in message
news:ct******** ***********@new s.demon.co.uk.. .

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.

Open IE6
Tools>Internet Options>Securit y 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
comp.lang.javas cript FAQ - http://jibbering.com/faq