Develop Reference

Javascript detection not working anymore

After this weekend my Wicket application cannot correctly detect javascript anymore. It doesn't work on my webhoster, on my local machine and I tested it also on another computer.
My detection script:
WebClientInfo clientInfo = (WebClientInfo)WebSession.get().getClientInfo();
if(!clientInfo.getProperties().isJavaEnabled()){
System.out.println("not enabled!");
WebSession.get().setClientInfo(null);
}
plus this in the application class:
getRequestCycleSettings().setGatherExtendedBrowserInfo(true);
I also created a wicket app from scratch, same result, no javascript detection.
While writing this I checked it in the Internet Explorer. Works fine with IE 8 + 9. Doesn't work with FF 11.0. Wicket version is 1.5.5.
Anyone can confirm this behavior? (possible JIRA-worthy...)
UPDATE: I found the cause of this behavior. isJavaEnabled checks if Java (not Javascript) is enabled. Firefox (silently) blocked the Java plugin on April 2nd, therefore no javaEnabled property set: https://addons.mozilla.org/en-US/firefox/blocked/p80. Cumbersome.

Likely this never worked, and the fact that it seemed to was dumb luck.
Looking at the javadocs for ClientProperties.isJavaEnabled(), it returns the client's navigator.javaEnabled property, which reflects whether Java is enabled, not JavaScript.
Java != JavaScript.

An alternative is to use the 'user agent' string:
public boolean javascriptSupported() {
WebRequest webRequest = (WebRequest) getRequest();
String userAgent = webRequest.getHeader("User-Agent");
if (userAgent == null || userAgent.startsWith("Googlebot")) {
return false;
}
return true;
}
I have used this to fallback on AjaxLazyLoadPanel for search engines, although you would need to expand on the list of user-agents above.
There is also WebRequest.isAjax(), which might be useful too, as it is used to determine the RedirectPolicy used, and thus, the behaviour of Wicket when Javascript is not present.

In what situation would document.open() return null?

I'm trying to understand an intermittent script error that I am seeing in a JavaScript intensive thin-client application running under Internet Explorer 6 and Windows XP. The root cause of the problem is that the following function call returns a null value (however it does succeed without an error):
var doc = targetWindow.document.open("text/html","_replace");
Where targetWindow is a window object.
Neither targetWindow nor targetWindow.document is null and so I'm struggling to understand why this call would return null. My interpretation of the documentation is that this method shouldn't ever return null.
This code has been unchanged and working perfectly for many years - until I understand why this is happening I'm not sure either how I might handle this, or what might have changed to cause this to start happening.
What might cause this function call to return null?

According to the documentation you should be passing "replace", not "_replace". Try this instead:
var doc = targetWindow.document.open("text/html", "replace");
Since you say your code has worked for years, then it is likely that something has changed and the above suggestion may not be the issue. However, it is still worth a try.
Have you changed any js files / libraries you are using in your application lately? Also, are you using any browser plugins within the page? It is possible that a newer version of either of these could be somehow affecting your call to "document.open".

document.open() does not have any parameters by W3C standard. Check out this link: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-72161170
I recommend you to use W3C documentation instead of Microsoft's one because with W3C you are sure it works on all modern browsers, while Microsoft is well known for adding extensions that, of course, works only in their own products. It's called EEE (Embrace, extend and extinguish).
Simply use document.open() without arguments. There are ways to manipulate user history, but that's called bad programming practice. History is user's private data and web application should not try to manipulate it.

browser identification

I want to identify if the broswer is IE then goto if block, other browser to else block in Java script.
I have one code here,
var browserName=navigator.appName;
if(browserName == "Microsoft Internet Explorer"){
IE code
}
else{
Other code
}
but i want to know is there any other way of implementing it?

Rather than do browser sniffing, you should do feature detection. Later versions of IE may support standards compliant stuff that in older versions you needed to work around or use MS-specific stuff.
Microsoft themselves have written up about the best way to do this and provide examples of both bad code (via sniffing) and good code (via detection). Make sure you go down the "good code" route.

I just started using this script to identify browser, version, and OS:
http://www.quirksmode.org/js/detect.html
If you are needing to use different code based on browser support for certain objects or methods, it's usually better to use object or method detection instead of browser detection. I use the browser detection for collecting statistics on my users, not for enabling or disabling features.
Quirksmode has a short article about why you don't use browser detection this way: http://www.quirksmode.org/js/support.html It's also linked from the browser detection script.

I found that This task is quite difficult as browsers all have similar names and different userAgent strings, so this is my Conditional statement to identify browsers.
I used this to identify the browser for different style sheets.
function styc()
{
var str = navigator.userAgent;
var res = navigator.userAgent.match(/Trident/);
var res2 = navigator.userAgent.match(/Firefox/);
if(res=="Trident"||res2=="Firefox")
{
//alert(navigator.userAgent);//for testing
document.getElementById('IE_fix').setAttribute("href", "IE_fix.css");
}
else
{
//alert("no");//for testing
document.getElementById('IE_fix').setAttribute("href", "mt_default.css");
}
}
Find a unique word in the userAgent string match it and check if the condition is true or not true depending on what you are doing.
The unique word I found for IE is Trident, and also identifies IE versions according to MicroSoft(not positive on this).

Which is a better way to detect a client's user-agent?

I am interested if which would be the best place to detect the client's user-agent, client-side (javascript) or server-side? I brought up the question due to the fact that some IE8 users are getting a message saying they're using IE6.

The short and correct answer is : do not use anything that relies on UserAgent sniffing.
To reliable be able to adjust code paths you should test for the specific 'thing' that the codepath is adjusted for, primarily features. This is called Feature Detection.
So if feature X is supported we do this, if not we do that.
Deducing if a feature is supported based on which UserAgent is present will rapidly fail, especially when new browsers come to the marked.
Take the following example, which can actually be found in several major libraries (!)
if (isIE8) {
// use new feature provided by IE8
} else if (isIE7) {
// use not so new feature provided by IE7 (and IE8)
} else {
// use fallback for all others (which also works in IE7 and IE8)
}
What do you think happens when IE9 comes along?
The correct pattern in this case would be
if ("addEventListener" in foo) {
// use DOM level 2 addEventListener to attach events
foo.addEventListener(...
} else if ("attachEvent" in foo) {
// use IE's proprietary attachEvent method
foo.attachEvent(...
} else {
// fall back to DOM 0
foo["on" + eventName] = ....
}

The User-agent available on both sides should be the same, unless there's funny stuff going on, which normally isn't.
If you want to show a message to IE6 users, I suggest you use conditional comments. They're an IE-specific feature and work very well for detecting IE versions.

The information found through client or server-side detection is basically the same.
Keep in mind it is extremely easy to spoof what browser you're in. There is no fail-safe way to detect all browser types accurately.

i don't know how you're checking for the user agent, but i'd do this way:
<%=
case request.env['HTTP_USER_AGENT']
when /Safari/
"it's a Mac!"
when /iPhone/
"it's a iPhone"
else
"i don't know :("
end
%>
checking directly in the user request seems to be the most consistent way to verify the user browser. And the request.env is avaliable in your controller and views, so you could pass this to rjs if needed.

For those who need to get the actual user-agent using JavaScript, you can use navigator.userAgent

New ActiveXObject('Word.Application') creates new winword.exe process when IE security does not allow object to be created

We are using MS Word as a spell checker for a few fields on a private company web site, and when IE security settings are correct it works well. (Zone for the site set to Trusted, and trusted zone modified to allow control to run without prompting.)
The script we are using creates a word object and closes it afterward. While the object exists, a winword.exe process runs, but it is destroyed when the Word object is closed.
If our site is not set in the trusted zone (Internet zone with default security level) the call that creates the Word object fails as expected, but the winword.exe process is still created. I do not have any way to interact with this process in the script, so the process stays around until the user logs off (users have no way to manually destroy the process, and it wouldn't be a good solution even if they did.)
The call that attempts to create the object is...
try {
wordApplication = new ActiveXObject('Word.Application');
} catch(error) {
// irrelevant code removed, described in comments..
// notify user spell check cannot be used
// disable spell check option
}
So every time the page is loaded this code may be run again, creating yet another orphan winword.exe process.
wordApplication is, of course, undefined in the catch block.
I would like to be able to detect the browser security settings beforehand, but I have done some searching on this and do not think that it is possible.
Management here is happy with it as it is. As long as IE security is set correctly it works, and it works well for our purposes. (We may eventually look at other options for spell check functionality, but this was quick, inexpensive, and does everything we need it to do.)
This last problem bugs me and I'd like to do something about it, but I'm out of ideas and I have other things that are more in need of my attention.
Before I put it aside, I thought I'd ask for suggestions here.

I have not found an answer to this problem, and I am disturbed at what the problem implies about Internet Explorer security (I forgot to mention in my previous post the version I am using : IE 7.)
However, I did implement a workaround that I am not happy with, but nevertheless feel more comfortable with than no check at all...
The code now attempts to open another object first, and if that fails the code assumes that Word will not open either and issues an error. From this point on, no more calls to new ActiveXObject() will be made and any attempt at a spell check will result in an error.
try {
oMSInfo = new ActiveXObject('Msinfo32.MSInfo.1');
} catch (error) {
// error handling code not shown...
return;
}
This object does not start a new process when the call to new ActiveXObject() fails. It also does not have a noticable affect on system resources.

If your browser creates an instance of an object, the object itself is not blocked by the browser security policies, except it is a security leak.
Try "application.visible=true", or "application.show()" to find out, where the application is asking for user interaction.
Hint: 'typeof application=="undefined"' means, the variable 'application' is not defined, where 'typeof application=="unknown"' means, more or less, it is a defined variable, stuffed with an external, proprietary object and if you really need to know how to handle it, read the manual -- pressing [F11] in any open window of the mentioned application could help in that case.
Might be a useful resource: https://learn.microsoft.com/en-us/office/vba/api/Word.Application