Intermittent IE CSS Menu problem

[martin42]

Using the CSSMenu system, I've got a nasty intermittent problem with Microsoft Internet Explorer browsers.  Now and again, for no apparent reason, IE will not draw the menus. Instead, it will draw a text version of the menus, like a site map consisting of nested tables.

I'd put this down to PHPLayers struggling to cope with MS IE, so I upgraded to the new beta to get CSSMenu. It happens a bit less often with CSSMenu, but it's still there.

In all cases, if the user clicks the Refresh button then MS IE will redraw the page correctly, but users may not know that!

I'm half-wondering whether MS IE sometimes just forgets to apply the stylesheet, because the site colours are missing and the page layout is vertical (tall and thin).  My pages do pass the W3C XHTML validator (1.0 Transitional), and the CMSMS and MSIE caches and temp files have been cleared.

Has anyone seen this problem?  Can anyone suggest a fix? 

http://imbatest.net42.co.uk

[Greg]

I had a similar problem with a web site that used PHP but not CMSMS, I eventually traced the problem to cookies. The stylesheet was dependant on the cookie being available.

Did you uninstall phplayers in the modules - I notice some CSS from phplayers still there.

[martin42]

Thanks for the note about PHPLayers.  Uninstalling that has shaved ~700 bytes off the stylesheet that gets sent to the browser.  But the problem's still there (even after flushing the IE cache and the CMSMS cache).

I'm kind of stumped. I guess I could try logging excatly what headers gets sent to the browser and see if there's a pattern to it.

I did wonder whether I could force consistent behaviour as a kludge, by disabling session handling for my HTTP site (no admin functions) by simply setting PHP.INI's "session.save_path" to something non-existent.  Well, it's interesting, because with session.save_path set to nonsense, the IE browser problem happens roughly one hit in three, rather than one hit in thirty.

I don't understand why sessions/cookies should make any difference for non-admin users (Read-only content), and even then, why does it only happen in IE?

[martin42]

UPDATE: I loaded the Burp Proxy on my MS IE test client, and accessed my CMSMS site from there, to log the traffic including headers.

RESULT: The bug does not occur when IE accessed the site via the Burp proxy!

So why is the site OK with IE through Burp? In theory Burp should not change the data. However, it does need to un-zip the GZIP compression that my PHP is sending.
So, it's conceivable that there's a bug in IE concerning GZIP decompression, that affects Style Sheets. Certainly the resulting messed-up page is as it would be if the CSS for the menu tree were being ignored...

A quick Google confirmed that IE has  a chequered past as far as Gzip decompression is concerned, and with particular reference to style sheets!  There's a hotfix available, but I don't know how applicable that is, and I don't want to download it as my site design can't depend on users having some obscure hotfix that Windows Update seems unaware of! 

So I've turned off compression in PHP.INI.  So far, the result seems to be that the IE bug is vanquished, at the cost of the site slowing down a little for all users.  It would be nice to turn off compression for IE clients only, but it's not obvious that PHP.INI supports that.

I did see a reference on Google to the effect that this IE bug doesn't occur if you use @import to import your style sheets. For example:

    @import url("css/blah.css");

rather than

   

I might try that once I'm 100% certain that disabling GZIP has really fixed this IE bug, as it would be nice to have compression back.

[martin42]

The good news is that turning off Zlib output compression in PHP.INI *does* fix the MSIE problem.
The bad news is that this increases my bandwidth usage greatly:

  GET /index.php                                    = 10928 bytes without compression, 3415 with compression (cool huh!)
  GET /stylesheet.php?template_id=21    =  3743 bytes without compression, 1369 with compression

I've tried editing content.functions.php and module.functions.php to send :   

Code: Select all

<style type="text/css">@import url("stylesheet.php?templateid='.$template_id.'");</style>

instead of

Code: Select all

<link rel="stylesheet" type="text/css" href="blah.css" />

and also tried sticking in large output buffers in PHP.INI.  No luck

My conclusion remains that MS IE for Windows just doesn't work reliably when compression is turned on. One page view in 20 or 30 will screw up, just when you think it's OK! 
It would be nice if there was some way to report this bug to Microsoft, but last time we tried reporting a (security) bug, they asked us for money before they'd talk to us! 
So I must disable compression for all browsers, just because Microsoft can't call a simple decompression library without buggering it up. 

Sorry for the rant. Hope this helps someone.

[martin42]

Here's a solution to serve compressed content to all browsers that say that can accept it, except buggy old Microsoft Internet Explorer.  This way, Firefox users don't pay for the bug in IE.

1. Edit /index.php and stick the following lines near the top, just before @ob_start():

Code: Select all

// Don't send compressed pages to MS Internet Explorer, because MS still hasn't fix their code.
if(isset($_SERVER['HTTP_USER_AGENT']) && preg_match('/MSIE/', $_SERVER['HTTP_USER_AGENT']))
{
  ini_set( 'zlib.output_compression','Off' );
}

2. If not already done, build PHP with Zlib compression enabled: pass "--with-zlib" to the Configure script before calling Make.  Then call "php -i" at the command line and check that "ZLib Support" is shown as "enabled".

3. In PHP.INI, turn on output_buffering and zlib.output_compression.  Might as well make the buffers nice and big if saving bandwidth is your main concern. If you're short of RAM then keep this down to something more modest.

    output_buffering = 65500
    zlib.output_compression = 65500

Now, if you fetch some site pages with FIrefox and then with MSIE, you'll see fairly drastic differences in the number of bytes sent down the wire. My index page is 3735 bytes compressed, 11703 bytes uncompressed.

[petert]

any reason why the simpler

Code: Select all

mod_gzip_item_exclude mime ^text/css

as described at http://forum.cmsmadesimple.org/index.ph ... 695.0.html isn't good enough?

[martin42]

Well, I'm not using mod_gzip or Apache for that matter, so I do need to control this from /index.php.

However, you may well have shed some welcome light on the issue!  If it's only compressed CSS files that screw up MSIE, then I'll try turning compression off for CSS pages only.

Thanks!

[martin42]

OK, after testing, it does seem that MS IE for Windows is safe with compressed HTML and uncompressed CSS.  Thanks Petert!

So the solution for my setup is to leave the original /index.php alone, but add to /stylesheet.php (near the top, just below 'require_once'):-

Code: Select all

if(isset($_SERVER['HTTP_USER_AGENT']) && preg_match('/MSIE/', $_SERVER['HTTP_USER_AGENT']))
{
  ini_set( 'zlib.output_compression','Off' );
}

So far this seems like a workable way to get compression back on my site. Though trying to prove that MSIE doesn't occasionally mis-render pages is kind of difficult!

[Ted]

Thanks for that.  I'm going to add it to svn.

[Cipolla]

First thanks to wishy for the link to this topic and to martin42 for his code sample and explanation. I put the code in the stylesheet.php below the 'require once' line.

Regrettably it didn't work or i did something wrong. My Testsite http://www.wfcauenkirche.de/index.php?page=Testseite is displayed correctly with firefox and surprisingly displayed nearly correct with an internet explorer 5.0. The internet explorer 6.0 displayed the site without CSS.

Any Ideas ? I am really confused.

[Ted]

CSS isn't working in Safari either...

That's a little strange, because if I open up the stylesheet url directly, the CSS is showing up.

Are you sure that you have all the right stylesheet's attached to the template?

[martin42]

Weird!

I take it you've flushed the CMSMS cache since the last edit or two, and that the browsers aren't set to "never bother fetching new page versions"?

[Cipolla]

Thanks so far. I proofed the attached stylesheets in cmsms and the corresponding tables with phpmyadmin. The allocation is correct. The allocation must be correct because firefox is displaying the page correctly. I also checked the options in both browsers to fetch the page always at access. I installed firefox at work to check if it is displayed correctly.

The result is as before. The page is displayed correctly in firefox, nearly correct in IE 5.0 and displayed without css in IE 6.0 under Windows XP SP 2.  I am at a loss what to do. Perhaps someone can check this locally.

This is the code of the template

Code: Select all

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<__html xmlns="http://www.w3.org/1999/xhtml">
<head>
{stylesheet}
<title>{title}</title>
</head>
</__body>
<!-- Seitenkopf -->
<div id="hdr">
<img src="TemplateBilder/Wappen.gif" alt="Wappen" style="float:left"></img>  
<img src="TemplateBilder/Feuerschrift.gif" alt="Feuerlogo"></img>
</div>

<!-- Inhaltsspalte -->
<div id="c-block">
<div id="c-col">
{content}
</div>
<!-- Ende Inhaltsspalte --></div>
<!-- end c-block -->

<!-- Fusszeile -->
<div id="ftr" align="center">
WFC Auenkirche
{current_date format="%d.%m.%Y"}
</div>

<!-- linke Spalte -->
<div id="lh-col">
<div class="blockhead"> Menü </div>
<div class="block">
{cms_module module='cssmenu'}
</div>
</div>
<!-- Ende linke Spalte -->

<!-- rechte Spalte -->
<div id="rh-col">
{content block="Variable"}
</div>
<!-- Ende rechte Spalte -->
<__body>
</__html>

This is the code of the stylesheet controlling the layout (There is also one for the calendar and the news modul)

Code: Select all

/* Layout Stylesheet */ 
body{
 margin: 0;
 padding:0; 
 background-color: white;
 color: #333333;
 }	 
	 
#lh-col{
 position:absolute;
 top:62px;
 left:0;
 width:160px;
 background-color: white;
 color: #333333;}

#rh-col{
 position:absolute;
 top:62px;
 right:0;
 width:200px;
 z-index:2;
 background-color: white;
 color: #333333;}

#c-block {
 width:100%;
 background-color: white;
 color: #333333;
 height:80%;}

#hdr{
 height:60px; 
 border-bottom:1px solid #000000; 
 width:100%; 
 background-color: rgb(140,170,230);
 color: #333333; 
 margin:0;
  }

#c-col{
 margin:0 202px 0 162px;
 position:relative;
 background-color: white;
 color: #333333;
 padding-left: 20px;
 padding-right: 20px;
 }

#ftr {
 width:100%;
 height:35px;
 border: solid #000000; 
 border-width:1px 0;
 background-color: rgb(140,170,230);
 color: #333333;
 margin:0;
 }

/* Ergänzungen */ 

.blockhead {
 font-size: 14px;
 color: #FFFFFF;
 font-weight: bold;
 background-color: rgb(100,135,220);
 padding-left: 10px;
 padding-right: 10px;
 padding-top: 2px;
 padding-bottom: 2px;
 width:150px;
 margin-top: 5px;
 }

.block {
 font-size: 11px;
 line-height: 1.2;
 font-family: verdana; sans-serif;
 background-color: #F9F9F9;
 padding-left: 10px;
 padding-right: 8px;
 padding-top: 5px;
 padding-bottom: 5px;
 border-left: 1px dotted #71A5EF;
 border-right: 1px dotted #71A5EF;
 border-bottom: 1px dotted #71A5EF;
 width:150px;
 }

#c-col h1 {
  color: white;
  background-color: rgb(100,135,220);
  font-size: 100%;
  font-weight: bold;
  margin: 1em 0 0 0;
  padding: 0.5ex 0 0.5ex 1ex;
}

#rh-col h1 {
  font-size: 100%;
  font-style:italic
  font-weight: bold;
}

To take a look at the phenomenon go to this page http://www.wfcauenkirche.de/index.php?page=Testseite.

[martin42]

Hi,

Well, have you proved whether the HTML and CSS is valid?  2 ideas:

1. Install "Burp Proxy".  Have IE6 connect to the web server via Burp Proxy (on localhost).  Then, if the server is sending compressed HTML or CSS, Burp will decompress the data before it gives it to IE6.

... or...

2. Save the pages to your hard disk, adjust the CSS include, then see whether they render correctly in IE6 and Firefox.

Are you sure that having names like "c-block" is legal?  I might try "cblock" or "c_block" just in case.

Good luck!