views:

420

answers:

3

I have an internal web application, that is IE specific, and uses a lot of IE specific modal boxes: (window.showModalDialog).

I recently received a request to remove the "flash" when navigating between pages of the site. To accomplish this, I just added a meta transition tag to my master page:

<meta http-equiv="Page-Enter" content="blendTrans(duration=0.0)" />

This works perfectly except for the modal boxes. When you launch a modal box, and then move it around, the web page behind it keeps a trail of the modal box instead of re-drawing the web page content. This prevents the user from moving the modal box to read anything that was behind it.

Is there a way to prevent the "flash" between pages in an IE specific site and have the site still work with modal boxes?

Please note, this is a large and complex site, so re-architecting it to not use modal boxes isn't an option.

This is an asp.net, c# web application, and all of my users are using IE 7 and IE 8 if it makes any difference.

-Edit-

To duplicate this, put the following into an html page, and open it in Internet Explorer:

<html>
<head>
    <title>Test</title>
    <meta content="blendTrans(duration=0.0)" http-equiv="Page-Exit">
</head>
<body>
<script language="javascript">
    window.showModalDialog('modal.htm', window);
</script>
</body>
</html>
+2  A: 

Have you tried the solutions from this page? It says you need to add a <link /> element to the head section (if you have the unstyled content problem [not the white-page problem]).

Also from Yahoo's Best Practices:

The HTML specification clearly states that stylesheets are to be included in the HEAD of the page: "Unlike A, [LINK] may only appear in the HEAD section of a document, although it may appear any number of times." Neither of the alternatives, the blank white screen or flash of unstyled content, are worth the risk. The optimal solution is to follow the HTML specification and load your stylesheets in the document HEAD.


Make sure you have a <link /> element in the head of all your pages and make sure that you put these stylesheets at the top of the head section and <script /> elements after them (preferably AFTER all page content and immediately before the closing tag).


I know you said you can't use modals but I thought I'd share this example of a JS modal using jQuery and facebox. You don't even have to modify your calls to "showModalDialog" (if you do end up using this modal method you can still use your meta page-exit page transition trick).

window.showModalDialog = function(a){
     $.get(a,function(html){
         $.facebox(html);
     });
};
window.showModalDialog('linkOnSameDomain.htm', window);
David Murdoch
Thanks for the reply, but I don't see how stylesheets are related to this. If you look at the sample page I put up, there aren't any stylesheets (or styles of any kind) involved.How would I modify the sample page I supplied with one of these solutions or best practices to fix the issue?
AaronS
Remove the `<meta http-equiv="Page-Enter" content="blendTrans(duration=0.0)" />` part (which is causing the re-draw problem) entirely. You shouldn't need it if you have your stylesheets and scripts in the correct order.
David Murdoch
Also, I did double check and all external stylesheets are referenced at the very top of the header of our master page. I misunderstood that you were addressing the core issue, and not the specific issues caused by the page transition I added.
AaronS
yah, sorry I wasn't clear on that. Are all of your script elements AFTER the stylesheets? do any of your stylesheets use @import?
David Murdoch
My rendered page head looks like this:Title, references to 5 stylesheets using: <link href="css.css" rel="StyleSheet" />, links to external javascript, some in-line javascript, then 10 or so lines of inline styles that are added by 3rd party controls.
AaronS
hm, sounds okay. you could try moving the JS to the footer.
David Murdoch
I found the .css files were also linked in some user controls. This resulted in being included more than once, in the header and in-line. If I remove these redundant ones, and move all of the .js links to the bottom, the flash goes away for a couple pages, but not every time. I'm also getting a bunch of JS errors because the in-line scripts need the external files, which they can no longer get to. This is getting me in the right direction for the root cause, but may be too much to tackle right now. So, for now, I will need to see if I can get the page transition trick to work. Thanks!
AaronS
Your welcome. It sounds like the project is a bit mangled and difficult to maintain. So, good luck! ----------- note: you can always just load an iframe into the facebox content (e.g.: '<iframe src=' + a + ' />' instead of $.get(...));
David Murdoch
Yeah, it's a project that was outsourced before I started here, and has since been brought back in house. I'm still trying to clean up stuff like this. I tried using your jQuery code to replace how we're handling modal boxes, but because the modal boxes have their own post backs and also launch other modal boxes, this won't work.Thanks again.
AaronS
Yikes, sounds painful. You could try doing a search on all your source code to replace window.showModalDialog with $.facebox.
David Murdoch
Accepting as the correct answer. I believe the root problem with the flash is a result of the way external files (.js, .css) are organized and referenced on the master page. Running a few tests showed that moving these around did fix the flash for a few pages. I will just need to get this working for everything across the whole project. Thanks again for your help.
AaronS
+1  A: 

Your problem is that showModalDialog isn't handling DirectX surfaces (which is what you end up with when you mess with filters and transitions). IE isn't performing screen updates on the underlying surfaces while the dialog exists. You have no choice but to stop creating those surfaces (stop using transitions) or to use a popup window as shown below. The only real difference is that the new window doesn't lockup the underlying page (which is generally a good thing but you may have to prevent further scripts running if your app relies on it) and you may need to handle any buttons in the dialog differently if you were returning results to the parent (like ok/cancel).

Be aware that IE8 security settings can restrict how much chrome you can hide. If you absolutely have to hide the address bar then you'll need to set "Allow websites to open windows without address or status bars" in the relevant security zone for each user PC.

<html>
<head>
    <title>Test</title>
    <meta content="blendTrans(duration=0.0)" http-equiv="Page-Exit">
</head>
<body style="background: transparent url(/images/backgrounds/brushed_aluminium.jpg) scroll repeat top left">
<script language="javascript">
    var modal = window.open('modal.htm', '_blank', 'height=500,width=600,status=no,toolbar=no,menubar=no,location=no,resizable=no,titlebar=no');
</script>

</body>
</html>
SpliFF
Thanks for the reply. Unfortunately, as I mentioned in my original post, re-architecting the site to not use modal boxes isn't an option at this point.
AaronS
+1  A: 

I would avoid built-in page transitions if at all possible.

If the "flash" you are referring to is the page reloading between requests. I would look at two different areas:

Caching

Consider placing images into CSS Sprites and/or making sure you have long expiration dates on your content files. If your page is flashing, it is because the browser is having to grab loads of stuff from the server on each request.

CSS Sprites - CSS Sprites are images that contain several smaller images in one file, which are then referenced using the background-position CSS property. The benefits of this technique are:

  1. Reduced requests to the server.
  2. Once one page has loaded, images on other pages are already cached in the browser (within the sprite).

Content Expiation - If your page is flashing, but page layouts are similar between pages. This could be a symptom that your server is forcing your browser to expire content between requests and re-download everything each time. Look at the headers being set on your content by IIS, or consider setting up a CDN.

A CDN is a web site purpose built for delivering content for another site. The key feature of a CDN though is that headers and cookies are disabled which makes requests quicker and leaves the caching entirely to the browser.

Ajax

If you want to avoid the page flash completely, you need to start putting your page requests through using Ajax style requests. Because you are using ASP.NET, you have a number of options at your disposal, below are two of them:

Update Panels - Update Panels scale quite well, in that you can put an Update Panel around a single button or an entire page. Everything within the Update Panel is posted backed to the server using an Ajax request an the panel is then updated with the results. No page flash at all! I don't use Update Panels in favour off the next option, which provides more control, but is more advanced.

jQuery & Web Services - What I've described above, but controlling the process using Web Services (or Page Methods) and jQuery's Ajax methods.

I hope this helps,

Rich

kim3er