Find out if Javascript is enabled

Discussion in 'Javascript' started by Alex Molochnikov, Jan 25, 2005.

  1. 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
     
    Alex Molochnikov, Jan 25, 2005
    #1
    1. Advertising

  2. Alex Molochnikov

    Mark Preston Guest

    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.
     
    Mark Preston, Jan 25, 2005
    #2
    1. Advertising

  3. 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, Jan 25, 2005
    #3
  4. "Alex Molochnikov" <> 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
     
    Alex Molochnikov, Jan 25, 2005
    #4
  5. 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.
     
    Richard Cornford, Jan 25, 2005
    #5
  6. "Richard Cornford" <> wrote in message
    news:ct6kk9$9uu$1$...
    > 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
     
    Alex Molochnikov, Jan 26, 2005
    #6
  7. Alex Molochnikov

    Mark Preston Guest

    Alex Molochnikov wrote:
    > "Alex Molochnikov" <> 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.
     
    Mark Preston, Jan 26, 2005
    #7
  8. JRS: In article <ct5ikb$2pd$3$>, dated Tue, 25
    Jan 2005 13:49:18, seen in news:comp.lang.javascript, Mark Preston
    <> 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.
     
    Dr John Stockton, Jan 26, 2005
    #8
  9. "Mark Preston" <> wrote in message
    news:ct8809$bvk$1$...
    > 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.
     
    Alex Molochnikov, Jan 26, 2005
    #9
  10. Alex Molochnikov

    Randy Webb Guest

    Alex Molochnikov wrote:

    > "Mark Preston" <> wrote in message
    > news:ct8809$bvk$1$...
    >
    >>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
     
    Randy Webb, Jan 26, 2005
    #10
  11. Alex Molochnikov

    Randy Webb Guest

    Dr John Stockton wrote:

    > JRS: In article <ct5ikb$2pd$3$>, dated Tue, 25
    > Jan 2005 13:49:18, seen in news:comp.lang.javascript, Mark Preston
    > <> 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.

    >
    >


    <--snip-->

    > 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?
     
    Randy Webb, Jan 26, 2005
    #11
  12. "Dr John Stockton" <> wrote in message
    news:...
    > 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, Jan 26, 2005
    #12
  13. "Randy Webb" <> wrote in message
    news:...
    > 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.
     
    Alex Molochnikov, Jan 26, 2005
    #13
  14. JRS: In article <>, dated Wed, 26 Jan
    2005 18:03:07, seen in news:comp.lang.javascript, Randy Webb
    <> posted :
    >
    >> 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.


    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.

    --
    © 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.
     
    Dr John Stockton, Jan 27, 2005
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gabor
    Replies:
    3
    Views:
    654
    Jacob Yang [MSFT]
    Aug 26, 2003
  2. Wybo Dekker
    Replies:
    1
    Views:
    388
    Yukihiro Matsumoto
    Nov 15, 2005
  3. vdvorkin
    Replies:
    0
    Views:
    433
    vdvorkin
    Feb 10, 2011
  4. vdvorkin
    Replies:
    3
    Views:
    846
    vdvorkin
    Feb 14, 2011
  5. oldyork90

    find it, cut it out, find next

    oldyork90, Jan 16, 2012, in forum: Perl Misc
    Replies:
    5
    Views:
    401
    John W. Krahn
    Jan 22, 2012
Loading...

Share This Page