Home     RSSRSS

Archives: Browser

Checklist for Troubleshooting Web Application in Internet

March 6, 2013 by kiranbadi1991 | Comments Off on Checklist for Troubleshooting Web Application in Internet | Filed in Browser, Development, Environment, Quality, Small Businesses

One of the hard things of troubleshooting the production issues is to identify the root cause of the issue. When the application is deployed in the open internet and accessed by the variety of the browsers, and has large number of hops in the network, it becomes quite a challenging task. So in this post I will walk you through the list of things which needs to be checked at high level on client side in order to identify the root cause of the issue and before proceeding to do the review of the code base.

Browser Setting

  • What is the proxy setting of the browser, does it access the application via proxy or connection is directly to the internet.
  • How is browser configured? Does the user have administrative rights or he has basic rights on the browser settings.
  • Is the browser configured to show user friendly messages? If Yes than can we reproduce the issue by removing those user friendly messages and just displaying the actual message which application is throwing.(Please note if your application does not do proper error handling, there exists a risk that you are displaying nasty code to the users. E.g. Famous yellow screens of the .net)
  • Is the browser configured to run in standard mode or compatibility mode? This point applies to IE. (Ajax and UI Issues are most often related to compatibility mode)
  • In case the issue is related to certificate, then checking whether the relevant certificate is present in trusted store often helps.
  • If your application uses popup windows to display some information, then checking if there are any add on or setting in browsers which is blocking pop ups also helps. Some browser add on silently block pop ups without giving any information to the users.
  • Is the browser setting on default? These are the setting which is factory default. One of the easiest ways to troubleshoot issues is reset the browsers to default setting.

Client Computer Settings

  • Is the client computer behind the firewall? If yes than verifying that it’s correctly configured saves lot of time.
  • Checking the antivirus software installed on the client machine also helps. Sometimes in case where your application uses specials character, there exists a chance that badly configured antivirus might filter out or block the incoming responses.
  • Hardware and software configuration of the user’s machine. In case if your application does lot of heavy lifting on the client side, then it often helps to educate the users that minimum configuration needs to be met.

Network Infrastructure and configuration

  • Is the network correctly configured? Using the bidirectional ping command often helps to identify the network issues.
  • Is the client able to resolve the application host name correctly?
  • Checking how many hops the user needs to make to connect to the server also helps
  • In increasing user experiences. General Thumb rule I often use is more the hops user does to connect to the server, more the response time he is going to get.
  • Is there any load balancer or firewall between the server and client? If yes than checking if they are correctly configured also helps.

User access or Login Issues

  • Is the user giving the right credentials and if yes then checking if server is doing correct validation of credentials also helps.
  • Is the identity and access validation done by application or by third party component like Site minder? If by third party, then checking the third party component in isolation often helps.
  • Does the user have appropriate access level to access the resources? If yes then further troubleshooting is required. Else its waste of time.
  • If browser is client, then disabling friendly error message settings in browser will reduce the time to identify the issue by almost 50% since no extra debugging tools are required unless the case if of missing or stolen headers.

Tags: , , ,

Javascript URL’s and Caching

January 1, 2013 by kiranbadi1991 | 2 Comments | Filed in Browser, Development, LoadRunner, Performance Engineering, SilkPerformer

In this post, I wanted to share some tips and also clear some misunderstanding which I have seen in lot many performance Engineer’s with regard to JavaScript URL’s which we often see during the Load testing of the Rich Client or web based Application which heavily uses JavaScript for rendering and manipulating the User interface.

I am sure lot many of us has seen url’s like below during their load testing efforts,

/mysite/js/myjsfile.js?1357011161255

The above url contains the unix style timestamp appended towards the end.There are quite a few reasons as why we append the timestamp the JavaScript,foremost reason being that we do not want to cache the JavaScript.Since these scripts are often interacting with DOM and building DOM Elements on fly based on the user interaction, it is a good thing in certain situations that we do not cache these type of javascripts.If browser caches these scripts, there exists some risks that we might see some browsers quirks happening at the UI.

Secondly, most of the JavaScript libraries which provides and implement XMLHTTP Requests implicitly uses these timestamp features.I know DOJO Library and Jquery extensively uses these timestamps while making Ajax calls so as to prevent the caching on the user’s browser.

One can easily implement these timestamps in their load testing scripts.I know both SilkPerformer and LoadRunner has built in Functions which supports creating and replacing the unix style timestamps.I suggest where ever you see these types of URL, just use those functions ,rather than commenting out those URL’s.If you are commenting out those URL’s, I feel you are building the scripts incorrectly and downloading at least 15% less bytes when compare to size of the entire page.

Also when you comment out these types of URL’s, you are doing less calls and thereby reducing the load on the servers.We need keep in mind that users never comment out anything and for these types of URL’s whenever they are present,browser will always be forced to make the call to fetch these JavaScript URL’s.There might be some performance impact on the application but again its choice between providing functionality and achieving performance.

However if you are developing Rich Client Web based application, then I suggest you to append your JavaScript files with timestamp in at least your development environment.It saves lot of time in debugging various client side issues and relieves you from clearing your cache every time you compile and build your code base.We need to keep in mind that browsers almost always caches JavaScript and css files and updated files are not available to application unless we clear all browser history and close and reopen all browser windows.Quite a painful process specially when we are implementing multi page functionality.

Tags: , ,

Dealing with Browser’s back Button with Headers and Javascript History Object

August 28, 2012 by kiranbadi1991 | Comments Off on Dealing with Browser’s back Button with Headers and Javascript History Object | Filed in Browser, Development, Environment, Others, Testing

Quite often while coding application which has lot of forms in it, there comes a requirement where in developers needs to deal with back button functionality of the browser.Disabling the back button with Javascript is one of the options used by many sites to deal with duplicate submission of forms.

Browsers maintain information about pages visited in the browser’s history and Javascript can be used to manipulate the history using windows.history object.

Some of the methods which we can use to know more about history are.

window.history.back();
This works exactly as back button of the browser.Goes 1 page back.
window.history.forward();
This works as exactly as forward button of the browser.Goes 1 page forward.
The number of pages in the history stack of the browser can be determined reading its length property,
window.history.length
We can go back and forth in the history  identified by using current position of the page,
 
window.history.go(-1);
window.history.go(1);
go function is used to load relevant pages from the history. go(-1) loads the 1 page backwards from the current page and go(1) moves the browser 1 page ahead from the current page.
 
HTML 5 History object also provides good way to deal with History management of the browsers, some of the functions in HTML 5 are as below,(Reference: Opera Dev Library)
  • window.history.length: Returns the number of entries in the joint session history.
  • window.history.state: Returns the current state object.
  • window.history.go(n): Goes backwards or forwards by the specified number of steps in the joint session history. If the value you specify is zero, it will reload the current page. If it would cause the target position to be outside the available range of the session history, then nothing happens.
  • window.history.back(): Goes backwards by one step in the joint session history. If there is no previous page to go to, it does nothing.
  • window.history.forward(): Goes forwards by one step in the joint session history. If there is no next page to go to, it does nothing.
  • window.history.pushState(data, title [, url]): Pushes the data specified in the arguments onto the session history, with the given title and URL (the URL is optional).
  • window.history.replaceState(data, title [, url]): Updates the current entry in the session history, with the given data, title and URL (the URL is optional)

History object of HTML5 gives us the tool to push/replace the url in the browser’s history and its this feature which I believe is somewhat in secure in nature.Maybe we can have some warning message whenever some scripts wants to read or write the history of the user’s browser exactly the way geolocation api’s work.

Anyways coming back to our topic, we can also use the javascript to control the behavior of the back button,one of the ways quite often used is

function disablebackbutton()
    {window.history.forward()}
disablebackbutton();
window.onload=disablebackbutton;
window.onpageshow=function(evt){if(evt.persisted)disablebackbutton()}
window.onunload=function(){void(0)}
This is most ugly way of dealing back button problem.Just disable it on onload and onpageshow events.

Another clean way of dealing with back button issue is tell browsers not the cache or store any information of the page in its history and this can achieved by setting appropriate headers.With Servlets and JSP , this can done  by

    response.setHeader("Pragma", "no-cache");
    response.setHeader("Cache-Control", "no-store");
    response.setHeader("Expires", "0");
    response.setDateHeader("Expires", -1);

These headers can be added to any page which requires that it should not be cached or reused in any way.I did go via header’s approach did resolve the back button issue.Now whenever I use back button I get Page expired message and for some pages form values are not pulled out from cache.

I would suggest going via header’s approach as this can be done at server side and has very limited or low dependency of the clients and most browsers honors those headers.

Technorati Tags: ,,,
 
 
 
 
 

Tags: , , ,