...

View Full Version : Can JavaScript function detect J.S. disabled?



mbl
11-07-2004, 08:19 PM
Dear friends,

On realizing that a minority of users (fortunately) may have JavaScript disabled at their browser, have used the <noscript> tags as is conventional.

However, was wondering if it is possible for a JavaScript function to contain code that when the function is called, an alert box would show stating something like "Your browser is currently supressing JavaScript functioning"?

Probably not possible, but then, how to know if not by asking?

Or is there other alternative to the <noscript> aproach?

Also, since JavaScripts is so useful and therefore popular, perhaps some message like that ought to be a property of the various browsers. Unless a script language is inherent in all of them, would say, and would like to know if there is such a concept going on somewhere.

Thanks.

-mbl-

Philip M
11-07-2004, 08:37 PM
If Javascipt is disabled it is er, well, disabled, and cannot detect anything.

The only solution is to have another page to which users without scripting enabled can be re-directed via the <noscript> tag.

Puffin the Erb
11-07-2004, 08:40 PM
You need to continue to put an appropriate message / link / instructions et al, in the <noscript> section. There is nothing wrong with using <noscript> on a page prior to JavaScript execution to act as an early warning.
This may be seen as a disadvantage of the client-side approach but then JavaScript should never be mission critical for a site's functionality.
One possibility to consider is to create a cookie using JavaScript. If the cookie is not created then the browser may not be capable of JavaScript and a server-side language could be used to warn the visitor to that effect.
Of course, there are other reasons why the cookie may not be created.

HTH

Willy Duitt
11-07-2004, 08:44 PM
Creating a cookie to detect javascript is a poor choice...
I have javascript enabled but cookies disabled...

Creating a var and checking for the variable would be sufficient....

But that is an interesting concept: using script to alert a user that they have script disabled

.....Willy

mbl
11-07-2004, 09:20 PM
Creating a cookie to detect javascript is a poor choice...
I have javascript enabled but cookies disabled...

Creating a var and checking for the variable would be sufficient....

But that is an interesting concept: using script to alert a user that they have script disabled

.....Willy

Yes it is a logical thought that kind of brings its own answer, but also bring this one: Since it is the Browser which turns JS off, then, would say it ought to be the browser which notifies the user of a JavaScript attempt, somewhat like is done for other security warnings when they are turned off.

Just found through google a while ago that 99.5% or so of users have JavaScript ON and since what am doing is not critical, will stay simple with a minimum of <noscript>.

Thanks for the replies, every one.

-mbl-

Puffin the Erb
11-07-2004, 09:29 PM
Hi there!
Bear in mind the stat is related to browsers that are capable of JavaScript.
Text-only browsers, for example, don't support it.

....... Willy, I don't understand your idea of creating a var and then checking for it.
What would you check for it with?
Sorry if I'm losing the plot.

Willy Duitt
11-08-2004, 02:26 AM
Yes it is a logical thought that kind of brings its own answer, but also bring this one: Since it is the Browser which turns JS off, then, would say it ought to be the browser which notifies the user of a JavaScript attempt, somewhat like is done for other security warnings when they are turned off.


If you disable active scripting you will find that those security alerts (such as those for ActiveX disabled) will disappear also since they are the result of VB script.... No script, no alert....

Puffin the Erb;

It depends upon your need and what you wish to do with the information if javascript is enabled or not... Generally, you would check if javascript is enabled and if so redirect to a javascript dependent page but you could also set a variable and send this value serverside to be processed depending upon your need...

.....Willy

brothercake
11-08-2004, 05:09 PM
Yes it is a logical thought that kind of brings its own answer, but also bring this one: Since it is the Browser which turns JS off, then, would say it ought to be the browser which notifies the user of a JavaScript attempt, somewhat like is done for other security warnings when they are turned off.
Well in the case of IE it can - you can set active scripting to "prompt". I have "cross frame scripting" in IE set to prompt so that I'm aware when a site is trying to do it - that's a security risk which I normally refuse, but my online banking doesn't work without.


Just found through google a while ago that 99.5% or so of users have JavaScript ON and since what am doing is not critical, will stay simple with a minimum of <noscript>.

I wouldn't put faith in that. Estimates I've read put it anywhere between 0% and 20% - I would go with 5-10% as a more realistic estimate (which includes robots themselves)

But anyway ... the script + noscript paradigm is not reliable, because it doesn't cater for primitive JS browsers like Netscape 3 or WebTV - they can't handle complex scripting, but they do support javascript, so they won't parse the noscript either.

The all-round best thing to do is do all your scripting in the DOM, binding methods to HTML elements which are there anyway.

Willy Duitt
11-08-2004, 07:38 PM
Just an FYI...

I have done alot of scripting for WebTv, particularly the older builds which were IE4 compatable (they just released a newer build based upon Windows CE and IE6 compatable) and they do support the <noscript> tags.... However, they (WebTv users) have no control and can not disable Active Scripting... Additionally, a problem arises due to WebTv taking a users requested page and prior to rendering the page for the end user they parse it on their server in an attempt to parse out any malicious code (ActiveX Controls, Javascript, VB Script, ect)... It is during this parsing that they convert script to their own forms of scripting known as Telly/Jelly script (much like vBulletin parses out HTML tags)... and often the resultant page does not convert completely leaving a run time error which kills any script on the page and effectively makes a script dependent page unusable.... In WebTv terms, this is affectionetely known as "The Javascript Bug" and the only known fix is to continue to reload the page until the script is properly converted to its Telly/Jelly script counterpart....

Of course this parsing/converting is much more entailed but the above is the simplist way I know of describing WebTv's behavior... But it should be noted that any malformed script which is throwing errors prior to converting to Telly/Jelly script will never have a chance to be problerly converted and the page will not have a chance to ever render properly despite how many times a WebTv user reloads the page and it is not unheard of for them to reload a page 15-20 times... :eek:

.....Willy

FastCougar
11-08-2004, 09:40 PM
The best way to determine this is on the server end with a product like Browser Hawk (http://www.browserhawk.com). I am using their product and redirecting users accordingly since my site requires javascript and popup windows.

brothercake
11-08-2004, 11:10 PM
I have done alot of scripting for WebTv, particularly the older builds which were IE4 compatable (they just released a newer build based upon Windows CE and IE6 compatable) and they do support the <noscript> tags....
My point exactly - they do support <noscript> - but if you run a complex script that it can't handle, it won't parse the <noscript>, because it does support the script.

But if you do all your scripting by sniffing for uplevel support and binding behaviors in the DOM to elements which are still there in plain HTML, you avoid these kinds of problems.

The best way to determine this is on the server end with a product like Browser Hawk. I am using their product and redirecting users accordingly since my site requires javascript and popup windows.
I wouldn't wanna rely on that ... unless they know something we don't, server-side browser detection is fundamentally unreliable.

Willy Duitt
11-09-2004, 01:04 AM
My point exactly - they do support <noscript> - but if you run a complex script that it can't handle, it won't parse the <noscript>, because it does support the script.

Please accept my apologies for any confusion I may have caused....

My memory failed me and I thought the <noscript> tag was used when the WebTv box suffered from the infamous "Javascript Bug" but I just checked my files and realized that a combination of <noframes> (WebTv does not support frames) and using script to document.write comment tags to the page was used instead....



<noframes><script>
if(navigator.appCodeName=='bowser'){document.write('<'+'!'+'-'+'-') }</script>
WebTv Javascript Bug! Press cmd+r for 5 seconds! WebTv Javascript Bug!! --></noframes>

.....Willy

brothercake
11-09-2004, 02:41 AM
Jeeze what a tedious bug. Well afaik the latest version is the MSN-branded 2.8 - does it still have that same problem?

Willy Duitt
11-09-2004, 03:16 AM
I believe the old WebTv boxes using the IE4 compatable browser are up to build 2.9 now.... However, they just released a new box, totally different from the old box... It's still in Beta Testing but they pushed release to get it into the stores for the Christmas Holidays... It's now called MSNTV2 and a link to their new site can be found here (http://www.msntv.com/pc/)....

I'm currently involved with a group whom is testing TNB and trying to figure out what part of the DOM is actually supported... However, things are changing erveryday and there still is a problem with popups and frames....

Additionally, several other Set Top Boxes have also recently been released (I would have to look for those links) but I am not familar with those other than they too are using Windows CE OS and a stripped down version of IE6....

Anyways, evidently some major players are still banking on networking Set Top Boxes with PC's to be used as media centers so it is something to keep an eye on...

.....Willy

BTW: In answer to your question... The old 2.8, 2.9 does still have the "Javascript Bug" and I'm pretty sure the new box does also but is not as prevelant and locks the box up and the only escape is to power off and reboot...

FastCougar
11-10-2004, 07:23 PM
I wouldn't wanna rely on that ... unless they know something we don't, server-side browser detection is fundamentally unreliable.I'd care to say that they know A LOT more than you and many others ... they have been doing this since 1994 and are used by countless fortune 100 companies (http://www.browserhawk.com/company/customers.asp) for their internet and intranet sites. I have used this product for the past year with absolutely no problems what-so-ever for a client portal.

jkd
11-10-2004, 07:45 PM
I'd care to say that they know A LOT more than you and many others ... they have been doing this since 1994 and are used by countless fortune 100 companies (http://www.browserhawk.com/company/customers.asp) for their internet and intranet sites. I have used this product for the past year with absolutely no problems what-so-ever for a client portal.

Server-side browser-sniffing depends upon the user-agent string, which is sent from the client. Some browsers make it 3 clicks to change the user-agent string, others may allow you to change it through a preference. Often times some major web apps work in Mozilla, but they send it to only IE browsers, and so the savvy Mozilla user changes their user-agent to IE in order to use it. That defeats the whole point of server-side side browser-sniffing.

Client-side sniffing is more effective for the simple reason that browser sniffing was never what you originally intended to do - it is really capability testing. If browser X can do this, give it code to do so. Not if browser X = Internet Explorer, give it code to do some particular feature. Feature-detection, not browser-detection is what app developers should worry about, and the easily-spoofable nature of user-agent strings makes content based on browser-detection a very risky business.

Puffin the Erb
11-10-2004, 07:56 PM
Correct.
Feature detection cannot be carried out reliably server-side because it inevitably relies on the HTTP_USER_AGENT string. This can be easily changed by the user.
However, the majority of Web users will not know, be able, and / or inclined to change this identifiying string so you may decide catering for the majority is acceptable even though it is not ideal.

brothercake
11-11-2004, 12:31 AM
I'd care to say that they know A LOT more than you and many others ... they have been doing this since 1994 and are used by countless fortune 100 companies (http://www.browserhawk.com/company/customers.asp) for their internet and intranet sites. I have used this product for the past year with absolutely no problems what-so-ever for a client portal.
Well if that's the case, you've been lucky - I just ran the test page on their site and it got quite a few things wrong - it said I supported DHTML when JS was off; said I support frame and iframes when I don't, and was unable to detect about 50% of the listed properties at all.

They don't know something I don't - they just don't have the same high standards. Who snifffs for all this stuff anymore anyway? You don't need to know anything like that much about the client environment if you're building sites properly

Honza
11-11-2004, 10:04 AM
Hi mbl
What about somewhere on a page "preload" warning message

<DIV id="warning">No Active scripting, whattodo, wheretogo..</DIV>

and later discard it with a script

if (document.getElementById("warning")){
document.getElementById("warning").innerHTML = "" //Scripting OK
}

mbl
11-12-2004, 03:38 AM
Hi mbl
What about somewhere on a page "preload" warning message

<DIV id="warning">No Active scripting, whattodo, wheretogo..</DIV>

and later discard it with a script

if (document.getElementById("warning")){
document.getElementById("warning").innerHTML = "" //Scripting OK
}

Dear Honza,

What you say is, would say, basically what have done. Have opted for a message that shows on the page that JavaScript is currently blocked by the browser and that some functions will not work.

Now, when they click on things, nothing happens. So, it is figured that if the reader is interested in seeing more, he'd be the one to decide.

And, friends, being a newcomer to coding, will say that am quite surprised that JavaScript being so useful and therefore important, it is blocked 'for security reasons'.

Why so? Does not this really mean that it is THE BROWSER itself which needs to be made secure? Or the operating system?

Now, it HTML can not do what JavaScript can do, then HTML is greatly lacking, would say.

Sounds as if at the times of black&white TV, color movies were to be blocked to prevent them from exploding a monochrome CRT.

Not too happy about all this. Sounds like we need an HTML that includes its own de-facto scripting that is always ON, and that it trusts and can hadle because it is its own.

Thanks everyone.

-mbl-

brothercake
11-12-2004, 04:20 AM
It's not that scripting is inherently insecure, it's that people exploit it to do two things:

1 - hack your system: but only Windows/IE has this problem because it's the only browser that has scriptable hooks into the OS. Companies often remove scripting at the proxy, and users often turn it off, because IE is not entirely safe if you don't.

2 - annoying stuff: like opening unrequested popups, changing the status field, or text that flashes different colors. People often turn off scripting to stop this kind of thing.

This is why scripting is optional, and with that in mind, good web development means allowing for either case equally, as much as possible.

Digital-Samurai
11-19-2004, 07:53 PM
Server-side browser-sniffing depends upon the user-agent string, which is sent from the client. Some browsers make it 3 clicks to change the user-agent string, others may allow you to change it through a preference. Often times some major web apps work in Mozilla, but they send it to only IE browsers, and so the savvy Mozilla user changes their user-agent to IE in order to use it. That defeats the whole point of server-side side browser-sniffing.

Client-side sniffing is more effective for the simple reason that browser sniffing was never what you originally intended to do - it is really capability testing. If browser X can do this, give it code to do so. Not if browser X = Internet Explorer, give it code to do some particular feature. Feature-detection, not browser-detection is what app developers should worry about, and the easily-spoofable nature of user-agent strings makes content based on browser-detection a very risky business.

Was wondering if anyone knows how to detect if ActiveX is enabled using client side script?

jkd
11-19-2004, 09:36 PM
Check for the existence of the "ActiveXObject"?

Like...

if (typeof window.ActiveXObject != "undefined") { /*bla*/ }

I don't know if it goes away when it is disabled though. When working with things like ActiveX, you should use try/catch blocks if you can:

try {
var wmp = new ActiveXObject("whatever.it.is");
wmp.play(/*or something*/);
}
catch(e) { alert("Error has occurred. Make sure that Active Scripting is enabled.") }

jettlarue2003
11-20-2004, 03:25 PM
i dont know if this would help but i have used it in the past
[CODE]
<center>
A code to let you check for Javascript.
<table border="2">
<tr>
<td colspan="2">
Check to see if you have <b>Javascript</b>
</td>
</tr>
<tr>
<td>
<SCRIPT>
<!--
document.write("You have Javascript!")
-->
</SCRIPT>
</td>
<td>
<noscript>
You do not have Javascript.
</noscript>
</td>
</tr>
</table>
i didnt test it so it mite have spelling errors:) :(



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum