Showing posts with label IE 8. Show all posts
Showing posts with label IE 8. Show all posts

Wednesday, March 9, 2011

31 reasons to hate IE. Styles not loading up?

Recently, I have been facing quite a few issues with IE.  And believe me all of them are really weird.  My hatred for IE is at all time high :)

I mentioned about a bug in IE8’s Lookahead Downloader in one of my previous post.  This post is dedicated to another such bug in IE.

What was the issue we were facing?

The problem we were facing was weird.  A page would render correctly on all browsers except IE (of course :)).

Yea, I know, nothing new about such behavior right?  But this issue is special in many ways.  Why?

Because:

I have decided to stay away from Telerik controls as much as possible.  If you asked me, I would only suggest to never ever, never ever, never ever, use them in your project.  The more I use them, more I get convinced not to use them ever.  

Why I hate Telerik controls so much?  

May be I will write that in a separate post.  

Why are we using it in our project?  

Client is not yet ready to move on.  

Anyways, Let me stop bitching about Telerik controls and focus on the issue we were facing.

The frameworks that we were using, assure that the site renders correctly on most modern browsers including IE.  Then why would it not render correctly on IE?

What were the rendering issues we were facing?

List box does not have proper styles
Alert box does not have proper style
Menu bar is unaligned and does not have proper styles

Look at the things highlighted in red in the above screenshot.

The issues we were facing were:
  • Sometimes List Box would lose its styles
  • Sometimes Alert box would lose its styles
  • Sometimes Tab Strip would lose its styles

Initially, I was really confused, didn't know what exactly was going on.  

Decided to intercept the HTTP traffic using Fiddler, to find out what is wrong with IE.  Why is it not sending requests for certain styles?

Found out that, IE does send requests for all style sheets.  But, IE just prefers to ignore a few style sheets (of course without showing any error)!  Typical IE, isn't it?

Googling a little we found that:
  • IE will load only the first 31 style sheets and will ignore the rest of the styles for a page request. This includes the <style> attribute tag as well if defined on the page
  • IE load only 4095 CSS selectors for a single request
  • On pages that uses the @import rule to continuously import external style sheets that import other style sheets, style sheets that are more than three levels deep are ignored.

Have a look at this link for more details.

That was it, we discovered another hidden treasure of IE!  Don’t we love IE for such hidden treasures?

The solution was simple enough, we removed few unused CSS references from the page.  Bingo, the page started working!

PS:  Why where unused CSS referred on the page?  Long story.  We will keep that for some other post.  Till then keep having fun with IE.

Tuesday, December 28, 2010

The thrill of being a developer - Fixing the problem of weird URL's

There are days when as a developer, I feel bored, bored to death, angry, happy, sad and many other emotions.  But there are a few days in life of a developer, when you feel truly thrilled!

Recently, one such thrilling day occurred in my life.

In one of the project, we were facing a weird and interesting issue in production.  The application server would get weird requests from the browser.  The weird thing about these request was that, the parts of the requested URL would be valid but, the end part would contain some weird html tags!  Since the resource would not be found on the server, app server would log the request and return a 404 error page.

For e.g. one such log message was:

The request that browser sent was:

The above URL is to fetch jquery.maskedinput.min.js file.  

Generally when an issue is reported by the QA/Client, I already have some idea as to what could have caused the issue.  But, this issue was special.  When I first saw these error, I was completely blank.  I had no idea what so ever why would something like this every happen!

We were using a pretty common Java stack.  Spring MVC and Hibernate, app was deployed on Weblogic server.  I had used these frameworks in so many other projects, but never ever faced an issue like this.

The most frighting part was, I had no idea what was the end user impact.  Was the user logged off?  Was he shown any error?  Did he see a garbled page?  No idea at all!

Coming back to the issue.

Yes believe it or not, the above request is to fetch the jquery masked input javascript! Notice that the beginning part of the URL is valid, but what gets added at the end is really not expected.

From where did

text get appended to the URL?

Digging a little deeper, I found something totally bizarre.  Turns out that the text

is present in the same page after some 4096 bytes!

How is it possible that something that comes after a few thousand bytes gets appended to the request URL of jquery.maskedinputments.min.js?

After two and half days of hard core googling, trying hundreds of different things with the script tag, the textarea tag, using different permutation combinations, and countless hours of analyzing the server logs over and over again, finally I have found a credible explanation to weird URL’s issue we were facing.

It happens because of a bug in IE8’s Lookahead Downloader.  The problem has nothing to do with the application!

What are you talking about?  Explain me in detail:

Following is an extract from this URL: http://blogs.msdn.com/b/ieinternals/archive/2009/07/27/bugs-in-the-ie8-lookahead-downloader.aspx which describes the bug in full detail.


Lookahead Downloader is used to quickly scan the page as it comes in, looking for the URLs of resources which will be needed later in the rendering of the page (specifically, JavaScript files). The lookahead downloader runs ahead of the main parser and is much simpler-- its sole job is to hunt for those resource urls and get requests into the network request queue as quickly as possible.

The problem here is that there are a number of tags which will cause the parser and lookahead downloader to restart scanning of the page from the beginning. One such tag is the META HTTP-EQUIV Content-Type tag which contains a CHARSET directive. Since the CHARSET specified in this tag defines what encoding is used for the page, the parser must restart to ensure that is parsing the bytes of the page in the encoding intended by the author. Unfortunately, IE8 has a bug where the restart of the parser may cause incorrect behaviour in the Lookahead downloader, depending on certain timing and network conditions.

The incorrect behavior occurs if your page contains a JavaScript URL which spans exactly the 4096th byte of the HTTP response. If such a URL is present, under certain timing conditions the lookahead downloader will attempt to download a malformed URL consisting of the part of the URL preceding the 4096th byte combined with whatever text follows the 8192nd byte, up to the next quotation mark.  Web developers encountering this problem will find that their logs contain requests for bogus URLs with long strings of URLEncoded HTML at the end.

Impact on the end user:

Generally this has no direct impact on the visitor's experience, because when the parser actually reaches a tag that requires a sub-download, if the speculative downloader has not already requested the proper resource, the main parser will at that time request download of the proper resource.  Hence,
  • The visitor will not notice any problems like script errors, etc
  • The visitor will have a slightly slower experience when rendering the page because the speculative requests all "miss"
  • IIS/Apache logs will note requests for non-existent or incorrect resources

The fix:

The fix is simple.  We needed to apply a IE8 Cumulative Update (KB980182) patch on the client machine’s which have this problem.

When I read this post, I was just stunned!  Problems like these truly blow your mind away!

Today, when I think about the problem, I realize that, its because of problems like these, I love being a Developer!

True developers, solve Real problems!

Saturday, October 16, 2010

How to run difference versions of IE (6, 7, 8) side by side on Windows 7/Vista

If you are a web-developer or a web-QA (QA who tests web-application), no matter where you work, what technology you use, what application you develop, there is always a need to test you application on various browsers.  Not just different browser from different vendors but different versions of the same browser. 

Although there are various ways in which we could get IE 6, 7, 8 running side by side on Windows 7/Vista.  All  of these techniques need installing some software or installing a VM image (which takes up approx 1 GB space on the hard drive).  In short its relatively long and painful process.

Some ways in which we could get various versions of IE running side by side are:

  • Installing IETester - Although its not a complete browser but shows the rendering of your application pretty well.  Works for IE 5.5, 6, 7, 8 and 9 (Great job IETester guys!).  Relatively pain free technique to test your application on various IE versions.  But its a difficult job to satisfy web-QA's, One of the QA's in my company said "I would not to believe IETester.  I want to test the application on actual IE 6"
  • Using the VM images - Relatively painful technique as it needs downloading VM images and Virtual PC software and a few more steps to get IE 6 and IE 7 running.
  • Another approach (again based on the VM image) is described here - In this approach IE6 window appears as a seamless window along with other applications running on your machine.  Nice approach, but still a lot of steps to get it running.
We need to test our app on various versions of IE but what about versions of Firefox, Chrome, Safari and Opera?

Web developers would agree that we need to test the application atleast on Firefox 2, 3, 3.5.


Sure there are ways to install them and get them running side by side, but none of them are as simple as clicking a button.

Although the title of this posts says getting different versions of IE running side by side on Windows 7/Vista, lets not ignore the other browsers and their versions.  Lets get them running on Windows side by side as well.

So how do we do it.  How do we get all these browsers easily?  It should be as simple as clicking a button.

How do they do it:

After all these years writing code, I have learned one thing and that is:

There always is a simpler way!  We simply need to find it.

Follow these steps to get different versions of IE, Firefox, Chrome, Safari and Opera running side by side on your machine, without installing too many software's on your machine.


 
  • It will ask you to install a plug-in so that you could run these browsers - Do that
  • After that if you hover over the image of any browser that you are interested in, you should see the green (power button) popping out - Click that
  • This will open up a dialog asking for user name and password - First time users can register for free - Do that
  • Next, A window will open up, this is an instance of your shining new desired browser - And you are good to go!

A note of caution: On slow internet connections this website could appear a little slow for the first run but subsequent runs are much faster.  Don't give up on it.  Its worth the wait!

That's it!  Have fun developing/testing your applications easily on various browsers and their different versions.
Have some Fun!