Showing posts with label IE6. Show all posts
Showing posts with label IE6. Show all posts

Thursday, December 6, 2012

IE6 SELECT element overlapping the front DIV element issue (Revisited) - An ultimate solution

It's been a very long time for IE6 to be deprecated while some organisations still insist on using it as a standard browser on Windows platform. IE6+WinXP is the best combination so far I have ever met such a dilemma on making the webapp advancing forward or coming back to take care of them.

"Well, customer first!", it bit me as the old man said.

Since we like easy fix, we would like to go a scripting way to deal with that. Actually, there's no easy fix at all until you know what you're doing.

Nice article with follow-up by an ASP.NET developer is found while it applies to any other projects using PHP, Python, Ruby or Perl. Anyway, we go for the way by using jQuery.

People are arguing about the way in using iframe to overcome a situation:


  • People work on web applications for IE6.
  • People think about using Javascript to create dynamic pop-up menu with DIV elements.
  • People would like to create DIV overlay on top of the current web page which has SELECT elements underneath.
  • DIV overlay can cover any other web elements except SELECT boxes and it looks ugly.

SELECT element is found to be one of the ActiveX objects in IE6 implementation. This doesn't apply to Firefox or Chrome or even Safari as they don't use ActiveX technology.

ActiveX is set to be higher z-index than any other web elements so it will always appear on top. This causes bad user experience while DIV overlay menu cannot cover a SELECT element. User may complain and say that your app has a bug. Well, a bug in IE6, indeed.

In an old way, we used to hide SELECT elements underneath but it's a bit out of control when the webpage contains some previously hidden SELECT elements and you don't want to make them appear again by accident.

As it's something about ActiveX objects, we go for the ActiveX way to resolve this.

Solution! Solution!

Among those ActiveX objects, IFRAME is fortunately one of them, too. So, we can make use of transparent IFRAME object to cover everything including existing ActiveX objects like SELECT. When a new ActiveX object is created after the old one, it would get the higher z-index on top.

Some people suggest simply embedding the IFRAME element into DIV container but it doesn't really work when accessing the webpage over SSL connection (HTTPS). Most secured web application would provide services over HTTPS. In this case, it will trigger an alert window with that Javascript statement in src attribute.


<div>

...
<iframe id="transparent_frame" src="javascript:false;"></iframe>
</div>

Here comes a better approach:


<div>

...
<iframe id="transparent_frame" src="javascript:'<html></html>';"></iframe>
</div>

This displays nothing but empty HTML page within iframe element. It simply keeps the browser silent over HTTPS and do the things we want.

Of course, we need to set CSS style for this IFRAME to be transparent and covering the whole area of DIV container (set your favourite width and height, please) so it will not affect any other elements within DIV container.

CSS Stylesheet:


#transparent_frame iframe
{
    position: absolute;
    z-index: -1;
    filter: mask();
    border: 0;
    margin: 0;
    padding: 0;
    top: 0;
    left: 0;
    width: 9999px; /* Set desired width */
    height: 9999px; /* Set desired height */
    overflow: hidden;
}

Is the problem solved? Not yet, it's bloody IE!

One problem that came across would be the memory leak in IE browser when we add new IFRAME dynamically by jQuery and then remove it. I can see the memory consumption of IEXPLORER.EXE increases dramatically in Task Manager until the system becomes unresponsive.

To avoid this, please make sure we are not creating new IFRAME one at a time when DIV overlay is shown up. Try reusing the same IFRAME to do the job and things would be fine.

In the experiment, a single IFRAME is created and reused until next page reloading without any memory leak issue on IE browsers which is good.


Ref:
http://weblogs.asp.net/bleroy/archive/2005/08/09/how-to-put-a-div-over-a-select-in-ie.aspx





Friday, November 18, 2011

Occasional blank page on IE6 during a site visit

Even though the market share of IE6 is on the way of shrinking around the world, the truth is many organization still deploy this particular version of web browser for LAN users. I always have a doubt on the statistics provided by IE6 Countdown website.

Anyway, I noticed some of the client computers are still running IE6 SP2 which is a bit better in security but still not flawless. IE6 is supposed to handle well in HTTP/1.1 connections and it always sends out HTTP/1.1 request. If not sure, have a look on the following URL and checkout the appropriate option to force IE6 to send HTTP/1.1 request:

http://www.ehow.com/how_6516962_fix-internet-explorer-provided-dell.html

Okay, even the client side is ready to handle HTTP/1.1, the proxy server or even the web server at the far side may not send back HTTP/1.1 response. In case of Apache 2.x server, the default settings make it suppress HTTP/1.1 response but send back HTTP/1.0 response instead, particularly for Internet Explorer.

You may find the settings under httpd-ssl.conf as follows:


#
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

According to EricLaw's opinion, this actually force Apache server to give out HTTP/1.0 response to any version of IE, even if IE sends out HTTP/1.1 request at the client side. This could lead to intermittent blank pages on IE6 which is actually error-prone to this kind of responses from the web server.


Some people suggest they simply comment out the settings to avoid this problem. Somehow, IE6 is not perfect enough if we don't put nokeepalive and ssl-unclean-shutdown directives into the filter. Other problems may still arise of IE6 or above version.

To overcome most of the problems among those different version of IE, we have put in detailed criteria to selectively tackle the problem of particular browser version.

The recommended settings would be like these:


#
#IE Version 2 to 5 should be downgraded to HTTP/1.0 for compatibility
#IE Version 1.0 not even support HTTP/1.1 so ignored
BrowserMatch ".*MSIE [2-5]\..*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
#
#Prudent settings for newer version of IE
BrowserMatch ".*MSIE [6-9]\..*" \
nokeepalive ssl-unclean-shutdown


Please beware of backward-slash plus double dots "\.." in the expression.

Except for some performance degrade on IEs, this should keep those browsers running fairly okay at the client side. In the far future, we might have to think about how to handle the case of IE10, IE11 or IE12 in case they are released. Hope those problems will be gone in the newer release of IE.

After all, Firefox, Safari and Chrome do not show any symptom like this in IE. So, finger crossed;)


Monday, November 7, 2011

In-depth look into Path MTU Discovery

Recently, I have been searching for a ultimate solution to remedy those situations whereas TCP traffic doesn't come through at the client side. The symptom could be occasional blank page on the browser.

It points me back to study the root cause of broken router or mis-configured firewall settings. For security reasons, some network administrator would make prudent settings to block ICMP traffic from the WAN whereas ICMP (type 3, code 4) packet is one key element in traditional Path MTU Discovery (PMTU-D) process initiated by the server.

Normally, MTU size is default to 1500 bytes at perfect network environment, especially the LAN. It's not the case in a real world situation where MTU size may vary. PMTU-D helps solve this problem in most cases. However, firewall administrator may simply block ICMP packet for security purposes. ICMP packet is useful for getting feedback from the destination for adjusting a possible MTU size to let the traffic come through without defragmentation, i.e., no further DF flag is required during the communication.

Hopefully, IETF Working Group has worked out another way to detect MTU without the need of ICMP packet. Packetization Layer Path MTU Discovery (PLPMTUD, RFC 4821) can work over the network layer above IP, i.e., TCP or UDP. This makes PLPMTUD can work independent of ICMP messages. It starts probing from a small packet size set as inital MSS, then increase progressively to a larger size until a packet loss happens. The optimum size will be used as MTU for that particular connection.

On Linux, there are several network parameters for tweaking:

/proc/sys/net/ipv4/tcp_mtu_probing
/proc/sys/net/ipv4/tcp_base_mss
/proc/sys/net/ipv4/ip_no_pmtu_disc


Possible values of tcp_mtu_probing are:
0: Don't perform PLPMTUD
1: Perform PLPMTUD only after detecting a "blackhole" in old-style PMTUD
2: Always perform PLPMTUD, and use the value of tcp_base_mss as the initial MSS.

Setting tcp_mtu_probing to 1 makes sure that PLPMTUD will start only when black hole router is detected along the way to the destination IP.

Default value of tcp_base_mss is 512 and is supposed to remain the same.

ip_no_pmtu_disc is default to 0 whereas traditional PMTUD can be used at all time. Setting this to 1 seems to make it totally skip the old fashioned way to detect MTU size by using ICMP message.

Ref:
http://kb.pert.geant.net/PERTKB/PathMTU
http://www.znep.com/~marcs/mtu/
http://kerneltrap.org/mailarchive/linux-net/2008/5/24/1928074/thread