Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Find out if Javascript is enabled

Reply
Thread Tools

Find out if Javascript is enabled

 
 
Alex Molochnikov
Guest
Posts: n/a
 
      01-25-2005
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


 
Reply With Quote
 
 
 
 
Mark Preston
Guest
Posts: n/a
 
      01-25-2005
Alex Molochnikov wrote:
> 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.
 
Reply With Quote
 
 
 
 
Alex Molochnikov
Guest
Posts: n/a
 
      01-25-2005
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


 
Reply With Quote
 
Alex Molochnikov
Guest
Posts: n/a
 
      01-25-2005
"Alex Molochnikov" <(E-Mail Removed)> wrote in message
news:wiuJd.169482$Xk.89165@pd7tw3no...
> 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


 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      01-25-2005
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?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.


 
Reply With Quote
 
Alex Molochnikov
Guest
Posts: n/a
 
      01-26-2005
"Richard Cornford" <(E-Mail Removed)> wrote in message
news:ct6kk9$9uu$1$(E-Mail Removed)...
> 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


 
Reply With Quote
 
Mark Preston
Guest
Posts: n/a
 
      01-26-2005
Alex Molochnikov wrote:
> "Alex Molochnikov" <(E-Mail Removed)> wrote in message
> news:wiuJd.169482$Xk.89165@pd7tw3no...
>
>>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.
>

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.
 
Reply With Quote
 
Dr John Stockton
Guest
Posts: n/a
 
      01-26-2005
JRS: In article <ct5ikb$2pd$3$(E-Mail Removed)>, dated Tue, 25
Jan 2005 13:49:18, seen in news:comp.lang.javascript, Mark Preston
<(E-Mail Removed)> posted :
>Alex Molochnikov wrote:
>> 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.



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.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
 
Reply With Quote
 
Alex Molochnikov
Guest
Posts: n/a
 
      01-26-2005
"Mark Preston" <(E-Mail Removed)> wrote in message
news:ct8809$bvk$1$(E-Mail Removed)...
> 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.


 
Reply With Quote
 
Randy Webb
Guest
Posts: n/a
 
      01-26-2005
Alex Molochnikov wrote:

> "Mark Preston" <(E-Mail Removed)> wrote in message
> news:ct8809$bvk$1$(E-Mail Removed)...
>
>>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>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
comp.lang.javascript FAQ - http://jibbering.com/faq
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to exclude action of Find::Find::find in subdirectories withknown names? vdvorkin Perl Misc 3 02-14-2011 05:28 AM
How to exclude action of Find::Find::find in subdirectories withknown names? vdvorkin Perl Misc 0 02-10-2011 05:18 PM
SOLVED: windows xp, "allow incoming echo request" greyed out. enabled. can't disable it jameshanley39@yahoo.co.uk Computer Information 0 06-20-2007 07:02 PM
Find.find does not find orphaned links? Wybo Dekker Ruby 1 11-15-2005 02:50 PM
trace enabled, get app. error, doesn't enabled, on runs without error Gabor ASP .Net 3 08-26-2003 09:54 AM



Advertisments