2

I've got a bizarre opacity issue dealing with IE8 & Websphere 6.1.

Got a very basic opacity setup where we have a modal type dialog box over-top of a certain screen. I put an opaque div over top of the screen in the background so the user can't click any of the controls but can see it, and then add the dialog box overtop & force them answer the question. Seemed very basic and was easy to do.

This is the css used to create the opaque effect described above:

.wipeOutDiv {
top: 0px;
left: 0px;
position: absolute;
width: 100%;
height: 100%;
background-color: #d9d9d9;
filter: alpha(opacity=70);
opacity: 0.70; 
}

This is the CSS used to create the dialog box:

.dialogBox {
position: absolute;
width: 350px;
margin: auto; 
z-index: 1;
background-color: white;
border-top:12px solid;
border-top-color: #ffd93f; 
border-left: 2px solid;
border-right: 2px solid;
border-bottom: 2px solid;
border-color: #ffd93f; 
padding: 8px;
top: 40%;
left: 40%;
font-family: arial;
font-size: 8pt; 
}

This scheme works fine in development across all browsers. Locally on my machine it works fine and on the integration environment it also works fine. Thought I was in the clear.

However, once it goes to our ST environment or above, the opacity fails to work correctly with IE8. It still works fine for Chrome & FF but for some reason IE8 fails to work correctly. The div using the 'wipeOutDiv' CSS class becomes totally solid and it looks strange. I've tried tinkering with IE's browser mode and document mode, but nothing I've changed has made it work in those environments.

I've compared the DOM documents between environments and they are identical. The only variable left to me is the Application server itself, which in this case is Websphere 6.1. I have noticed one difference is environments where it works are served via http and environments where it doesn't are https. This seems like more of a coincidence than an actual root cause.

I'm pretty miffed. Anyone have any suggestions or similar experiences?

Durandal
  • 5,575
  • 5
  • 35
  • 49
  • 2
    Did you also compare effective CSS parameters in both cases? I can only think of CSS resource file is not being loaded properly over HTTPS for some reason. It makes sense to enable HTTP access log on WAS and check for errors - http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/ae/utrb_httperrlogs.html – ﾤ ﾡ Jun 26 '13 at 20:08
  • Yeah I dug into the CSS params in the pages; they are the same but both do have a strange artifact. It stacks two values onto the same line. See the image: [Image](http://tinypic.com/r/o5rxna/5) I'll have to look into the HTTP log on WAS and see if anything shows up. – Durandal Jun 26 '13 at 20:50
  • 1
    Is operating system that you use to author CSS files the same as the one where WAS is running? If they are different, could it be so that end-of-line characters are not converted properly? – ﾤ ﾡ Jun 26 '13 at 21:03
  • The development OS is Win 7 and target OS MS Server 2008. I also noticed the CSS values are randomized/out of order in IE vs Chrome where the order matches exactly as they are listed above. It seems like IE is reordering the css arguments; not sure if that matters though. I looked at the HTTP access log on the WAS 6.1 instance and there are no errors in there. Running out of things to check at this point. – Durandal Jun 27 '13 at 16:00

1 Answers1

1

This ended up being an issue with IE enabling "Protected Mode" on a non-trusted site by the local machine. The IE opacity hack requires using an outside .DLL file and IE won't let that happen without protected mode being enabled. This was only solved when someone's machine worked correctly in production and they noticed they had the site added to the trusted list.

Durandal
  • 5,575
  • 5
  • 35
  • 49