Why Does IE Resize My Dialogs?


Hi, Travis here, a program manager for Trident/OM. In Beta3, you may have noticed that modal or modeless dialogs created from script seem to be slightly bigger than their IE6 counterparts. This is due to a recent change to bring the behavior of these dialogs closer to their window.open cousins. In essence, we want to free developers from worrying about how much content size they are going to get when they request a modal or modeless dialog (from IE7 and onward). Note: our definition of content size is the actual window area available in which to display web content (see Figure 3).

To see the size difference, consider the following script that fires a new window via window.open and a dialog via window.showModalDialog.

Table 1

<script type="text/javascript">
function fireWindowOpen()
   window.open("about:Blank", "_blank", "width=300px,height=200px");

function fireShowModal()
   window.showModalDialog("about:Blank", null, "dialogWidth:300px;dialogHeight:200px");
<input type="button" onclick="fireWindowOpen()" value="Open via window open">
<input type="button" onclick="fireShowModal()" value="Open by modal dialog">

In IE6, the window.open window is created with 300 x 200 pixels of useable content area (this is good). The modal dialog is created with slightly less useable area. Why is that?

IE6 gives web developers control over the frame size of dialogs (also known as the ‘chrome’). The frame includes visual elements such as the title bar, status bar, borders, etc. This is a problem for web developers because the dialog’s frame size varies according to whatever windows theme is applied (this is bad). With Windows Vista on the horizon, new user themes compound this problem (see figure 1).

Figure 1 - Various themes in Windows XP and Vista and their content area
Comparing Themes in Windows XP and Vista

In Windows XP Service Pack 2, IE’s security improvements added window restrictions that forced the status bar onto windows and dialogs (in certain security zones); developers adapted by subtracting the height of the status bar from their dialogs.

Enter IE7. We bring you another security feature—an address bar for identifying a dialog’s URL (see figure 2). This address bar also encroaches upon a dialog’s content area.

Figure 2
Address Bar for identifying Dialog URL

Before the guesswork for sizing the content area gets any worse for developers, we felt it was time to set things right by focusing on delivering HTML content area instead of total frame size.

Here’s how we changed it. In IE7, the meaning of window.dialogHeight and dialogWidth now refers to the content area. Essentially, the area (height/width) that you specify is what we try to deliver in the content area of the dialog (barring window restrictions on scriptable minimum sizes: 250px wide x 150px high*). It will no longer be necessary to calculate the area lost by components of a dialog’s frame.

Figure 3
Comparing IE6 to IE7

Based on these changes, websites that must continue to support IE6 and want IE7 dialogs to look identical must either provide special case code for IE6 and previous versions, or special case code for IE7 and beyond. My browser detection code (below) borrows from an article on effective browser detection techniques.

Table 2

Method 1: For IE6 code that previously adapted window size to meet the requested content area dimensions--before calling the new window

Method 1: For IE6 code that previously adapted window size to meet the requested content area dimensions--before calling the new window
<!-- Code in the calling window (the window that opens the child window)
Note: your code probably assumes the “adjusted” height/width already -->

<script type=”text/javascript”>
// Setup variables...
var desired_width = x;
var desired_height = y;

<!--[if gte IE 7]><script type=”text/javascript”>
// Just make the window how big you want your content...
window.showModalDialog(“about:Blank”, null, “dialogWidth:” + desired_width + “px;dialogHeight:” + desired_height + “px”);

<!--[if lt IE 7]><script type=”text/javascript”>
var title_bar_estimated = 29; // 29 pixels or so for XP, 22 for Win2K...etc.
var chrome_thickness_estimated = 2; // about 2 pixels or so...
// For Service Pack 2

var status_bar_estimated = 25; // Roughly 25 pixels or so...

var adjusted_width = desired_width + (2 * chrome_thickness_estimated);
var adjusted_height = desired_height + (2 * chrome_thickness_estimated) +
title_bar_estimated + status_bar_estimated;

window.showModalDialog(“about:Blank”, null, “dialogWidth:” + adjusted_width + “px;dialogHeight:” + adjusted_height + “px”);

Method 2: For new IE7 code to work backward with IE6--adjusting the size after the dialog is created

Method 2: For new IE7 code to work backward with IE6--adjusting the size after the dialog is created
<!-- Code in the new (child) dialog -->

<!--[if lt IE 7]><script type=”text/javascript”>
// IE 6 and previous versions add chrome elements into my requested dimensions.

// window.dialogHeight/Width gives the frame size in IE6. In IE7 it gives you the content area size.
var estimated_total_chrome_elements_width = 4; // left and right frame edge
var estimated_total_chrome_elements_height = 29 + 25 + 4; // title + status bar

window.dialogWidth += estimated_total_chrome_elements_width;
window.dialogHeight += estimated_total_chrome_elements_height;

IE7 no longer provides a method for script to retrieve the dialog’s frame dimensions (‘chrome’ area included). This was formerly available through window.dialogHeight/Width, which now returns the content area. Future versions of IE may provide this functionality. In IE7, if the total window dimension is desired, it must be estimated using the same techniques from IE6 used to estimate the content area (but in reverse).

At this risk of complicating this post, I also want to enumerate two security settings that may affect how developers design for new windows and dialogs in IE7 (figure 4).

Figure 4
Windows Security Settings Dialog

Window Restrictions Setting

What changed: This setting controlled both windows sizing constraints (minimum sizes), and the forcing of the status bar in SP2. IE7 has combined the forcing of the status bar and the new address bar into a new setting, as the two visual elements are important for security and should be considered together (see below). The window restrictions setting now applies only to sizing constraints. Restrictions are turned on for the Internet, Restricted Sites, and Lockdown zones.

Status and Address Bar Control

This new setting allows users to enable or disable the forcing of the status bar together with the forcing of the address bar on a per-zone basis. If enabled, the address bar and status bar will display on dialogs despite the developer’s scripted code (status:on or status:off will be overridden by this setting). Disabling this setting allows developers to continue to specify the presence or absence of the status bar and address bar independently of each other. Restrictions are enabled for the Internet, Restricted Sites, and Lockdown zones.

We think that the transition to this new sizing model (content area vs. total frame size) will benefit web developers in the long run by making it simpler to code pages that will display in dialogs or windows.


*As many customers have pointed out, the minimum sizes for dialogs across IE have been adjusted in IE7 from their previous limits. In IE6 new windows via window.open had a limit of approximately 100x100 pixels of content area. New dialogs via window.showModal/ModelessDialog had a total frame height and width limit of approximately 100x100 (the width value was always approximate because Windows itself enforces additional minimums based on current theme). IE7 changed the width minimum to ensure that the newly-added address bar displays enough URL text to make informed trust decisions, to allow the status bar to fully print “Internet | Protected Mode: XX” without truncation (in Vista), and to avoid truncating the address bar widget (the widget starts to truncate at 204 pixels). The height was adjusted to match new window.open minimums. Thus in IE7, usable content area minimums are uniform across both window.open and window.showModal/ModelessDialogs.

Edit: Please see the update blog post on IE7 dialog sizes for the most current information on minimum dialog height restrictions

Comments (41)

  1. golad says:

    You’ve just broken every showModalDialog that’s currently in use. I can’t even begin to describe how irresponsible this is.

    You could have easily introduced this alleged "better behavior" with a special property that enables it in the 3rd argument (say "dialog-sizing:content", for example). Instead you decided to break literally thousands of web-sites and web-applications because "you felt it was time to set things right". Unbelievable.

    I thought that when it came to backward compatibility Microsoft can be trusted. You even kept quirks-mode working well when you introduced the standards-fixes to IE6, depending on doctype. Why mess this up now?

    Changing the behavior of a method just because someone felt like it (literally!) is simply outrageous. The IE team of 1999 would never do this. How disappointing.

  2. Dave Massy says:


    Can you explain exactly how this breaks every dislog. Some dialogs may be a little larger than before but I don’t believe that should cause any serious break of funcitonality. Had we felt this was going to seriously break functionality we would not have undertaken this change.



  3. golad says:


    I believe that breaking something visually is sometimes every bit as offensive as breaking something in functionality. I’m sure the CSS team will agree here.

    For example, if you suddenly decided to change the definition of "red" in IE CSS to result in blue, it would not break too many interfaces functionality-wise. But it will make a bunch of them look pretty bad though (aka breaking them visually). Some of the UIs may also be completely unreadable in certain conditions.

    Back to the dialogs at hand. Having a gap ranging between 25 and 50 pixels (depending on chrome) at the bottom of a dialog is pretty "Bad" and confusing from a UI standpoint. I’m sure no one at Microsoft would dismiss it if a change in dialog size calculation would result in dialogs spawned via MessageBox to appear "a little larger".

    As for pure functionality problems, some dialogs naturally rely on the current definitions of dialogHeight and dialogWidth and read/write to them accordingly (according to various calculations). Changing their meaning may cause functionality problems in quite a few dialogs (hidden content, visible content that should be hidden, etc).

  4. Dave Massy says:


    If you can give us an example of a break of functionality then we will definitely take a look. These changes have been in IE7 for some time and we have not seen any breaking issues. I agree that changes in CSS definitions are serious and as you point out we do take those extremely seriously. For dialogs we felt this change was the correct thing to do. I don’t believe that a visual change to a slightly taller dialog which would be inconsistant anyway depending on the visual style that the user has selected for Windows is the same as a break in functionality.



  5. Gordon says:

    golad: I seriously hope that your post was a joke post.

    "The IE team of 1999 would never do this. How disappointing."

    The IE team of 1999 (and before) should have got it right in the first place. Microsoft needs to start breaking things if they ever want to clean things up. You can’t maintain backwards compatibility forever, or else you limit the progress that you can make.

    Your suggestion of a special (proprietary) property is a step in the wrong direction when Microsoft has finally started getting on track.

  6. golad says:


    No joke.

    Yes, they should have gotten it right to begin with. They didn’t. People worked around the size issue. People used what was available. Companies invested man hours in a solution. Microsoft wants to make things right by making a whole bunch of things wrong and essentially create yet another condition where we have to code ugly version-specific hacks. They didn’t have this mindset when introducing CSS standards fixes back in 1999 (see quirks-mode), they shouldn’t have it now.

    Introducing a new meaning to existing objects will cause much more havoc than introducing a new property ("proprietary" is completely irrelevant as showModalDialog itself and its properties are already proprietary) to dialogs.

    Microsoft managed to move forward quite well and still religiously kept core backwards compatibility, it is possible. That’s why you can run Windows 95 programs on Vista. Keeping backwards compatibility doesn’t mean limited progress, it means you respect the efforts that your customers have invested in the past.


    There are currently solutions in place for dialogs to display in the correct height regardless of chrome size, by observing dialogHeight, scrollHeight and offsetHeight and adjusting dialogHeight accordingly. These will no longer function correctly (as they assume dialogHeight includes chrome). This can lead to functional problems.

    Imagine a UI similar to the IE error dialog, where you can click a button in order to extend the height and see more of the UI. With the recent change, parts of the "extended UI" may already be visible. This could possibly create situations the programmer had not predicted and cause functionality problems.

    Naturally, that’s just one example and I’m sure you can come up with more yourself. You could argue how common or uncommon each scenario may be, but you can’t deny that functionality problems CAN occur because of this new behavior.

    I urge you to please reconsider your changes.

  7. davis says:

    golad, how are you handling the current situation? Whereby the size of dialogs will vary depending, inter alia, on whether a Windows XP user has visual themes on or off? You cannot tell the height of the "chrome" elements as the situation currently stands, so whatever you have written to date will only be an estimation and will certainly fail for anyone with a non-standard window title bar height.

  8. Bill says:

    Worse still, such approximations will fail when the user has a high-dpi display, which is becoming more and more common with Tablet PCs and high-res flat panel displays.

  9. Alfonso says:

    Congratulations for this change.

    This is a very welcome fix because it doesn’t have any sense for a web author to care about what’s outside its scope as it happens to be with window’s chrome. Now it will be so much easier to open windows with just the correct size and doesn’t matter if the user has a status bar, url bar or whatever, I just wish that everything would behave like this.

    Thank you.

  10. golad says:

    Bill, Davis,

    The chrome height can easily be calculated.

    If you open a dialog with the height of 300px, and when it loads you measure its document.documentElement.offsetHeight and get 270px, then you can make the simple conclusion that the chrome is 30px and compensate for it (set window.dialogHeight). This is not an estimation or approximation, it’s a precise calculation and it works wonderfully on any type of chrome.

    I’d just like to emphasize that this change isn’t "bad" in itself, it’s great to be able to open a dialog based on content size. But the price is just too high if you change how the method works by default. Adding a property that enables this content-sizing mode will keep the great new functionality without breaking existing dialogs.

  11. Andy Lann says:

    @davidp: Probably ’cause IE never will get the floating right on divs. Can’t believe I have to add *another* clear floats fix just for IE7, but I guess that’s another discussion.

  12. Steffen Weber says:

    It would be very useful that while on this trip you´d implement support for Mozillas and Operas innerWidth and innerHeight property of the window object. Because only then one can actually _resize_ a popup window to fit perfectly.

  13. Brett Merkey says:


    This article is clear and helpful. At least I have the information that will aid in future-proofing the applications I am responsible for.

    I saw all my carefully calculated modal/modeless dialogs go bad with the beta. Scrollbars appeared, hiding important functionality in popup calendars and other widgets. Months ago we put in failsafe adjustments to prevent worse-case scenarios altho the result was aesthetically noxious in IE7.

    On the basis of this article it will be possible to make future adjustments dependably.

    Still, it would be better to strive for more conformance to equivalent approaches used in Firefox.


  14. Steve says:

    Ok, so what about the minimum width?… in IE6 and below (and (cough) every other browser) the minimum width was 100px.  Now, in IE7, the minimum width is ~240px.

    This makes calendar popups and such look horrible.

    Since no chrome, is requested, there is no need to provide the default tab width.

    Is this going to be fixed before final release?

    PS I’ll add a ticket to feedback, for your reference.

  15. Steve says:

    Mozilla has a great little method on windows, called .sizeToContent() , which automatically fits the window to the content.

    Since MS is messing up all the dialog sizes, is there any chance you can implement this method also, so that we have less calculations to fight with when modifying our final designs to work in IE7 as well as it does in all other browsers?


  16. TMaster says:

    Good job, guys.

    If I were you, I would take a quick look at the security settings names, though. Some of them are less than crystal clear, just look at the window restrictions setting. It makes it sound as though the windows will be blocked when you use the "disabled" setting, while I’m quite sure that’s not the case.

    How about "Allow unsafe window dimensioning/positioning"? Or perhaps someone can think of something even more obvious.

  17. PatriotB says:

    "It would be very useful that while on this trip you´d implement support for Mozillas and Operas innerWidth and innerHeight property of the window object. Because only then one can actually _resize_ a popup window to fit perfectly."

    "Mozilla has a great little method on windows, called .sizeToContent() , which automatically fits the window to the content.

    Since MS is messing up all the dialog sizes, is there any chance you can implement this method also,"

    Hmm, I did a search to see what standards innerWidth/innerHeight/sizeToContent were from.  But I didn’t find anything! (except innerWidth/innerHeight in an SVG standard).  Sounds to me like Mozilla and Opera are implementing proprietary features?  Why do they get away with it, when MS gets slammed for proprietary features?

  18. RussS says:

    Two comments:

    (1) I agree with the comment about calendar-like widgets. The new wide widths have made the modal many modal controls too wide. Honestly…with all the security stuff now forced to the top and bottom of the frame (already making controls look ugly) this was is just too much. It makes applications look amateurish.

    (2) The minimum "scriptable height" of the content area is also larger (you can manually make it smaller but not with a script) makes dialogs that act like alerts  way too tall. For god sake, if we know we need less content minimum space please let us control it. (I have implemented many where I want to have buttons say something different than OK/Cancel … or if I needed 3 button options.)

  19. PatriotB says:

    I would think that Calendar-like widgets would be better implemented as absolutely-positioned HTML elements?  Why open a whole new window?

  20. Jean-Christophe says:

    As a (web)designer I understand the scope of the problem and its solution. But wouldn’t customers benefit from a much clearer settings pane? The option to "fix" visual annoyances are buried in a very long list, in a pane located many clicks away from IE7’s main interface. I – myself – have hardly any luck finding what i am looking for when I need to configure something in IE. It’s a bit frustrating considering the amazing work done on the main UI.


  21. insane-minimums says:

    Please vote for bug #155164 (started almost 2 months ago) in order to make the minimum dialog sizes sane again.

    And if anyone has a right to change it from "Resolved" to "Open", please do.

  22. Anders Jenbo says:

    Thank you thank you thank you, i only whis this had been thourght of in IE3.0

    This will fix all popus that was displaying wrong in IE6.x and we can now make much much nicer popups for IE7 and risk takers like me 😛 can get rid of the additional bars, i am very gratefull for theas changes i would just have wished it was the same for all browsers since the dawn of time.

  23. Brutus says:

    Good change.  Of course, it should’ve been like this all along (and should’ve been obvious, since Windows programs usually deal with the content size of windows rather than the total window size).

  24. Sujay says:


    Not just IE7 RC1.. I’m on good old IE6 (I see no reasons to upgrade) and I see the same space below his 1st paragraph..

    As for the main problem of weird dialog sizes, I have simply stopped supporting anything beyond IE6 on the web apps I make.

    And… although I have nothing to do with this URL or website, this is what may eventually happen if MS continues its juggernaut of breaking things that were "just fine" before:


  25. Would not it be better to have introduced another property like contentHeight/Width or innerHeight/Width or minHeigth/minWidth or simply height/width (like in windows.open) for dialogs and to keep the existing semantics of dialogHeight/Width (the actual height/width of the dialog frame)?


    1 "backward compatability" (for those sites that specifically have implemented a strategy to deal with the varying chrome dimensions)

    2 ability to set the exact size of the dialog frame (e.g. to full screen)

  26. Steve says:


    True, Calendars are better as HTML widgets, but lets not forget, that we often need to support IE6 too (even 5.5 or 5.0) in some cases.

    In those browsers, there is the "oh-so-ugly" select z-order bug, that messes them up.

    Yes, there are 2 hacks to get around this… hiding the selects (looks ugly, causes screen jumping), or the iframe hack, which (a) is just a severe pain to implement.. and (b), breaks if the user scrolls using the mouse wheel.

    Most "widgets" of any kind, can be done now, with a little HTML, AJAX, and time… but for existing applications, making the changes from a simple HTTP popup window, to a DHTML/AJAX widget, are a big pain, when they work just fine as is (e.g. the old saying, if it ain’t broke, don’t fix it)

    I have no quams with the new width dimension properties… they’re all easily adjusted… what anoys everyone here, is that in the "name of security", the min-size of the window has changed, and surprise, surprise, there is _NO_ security enhancement provided by the change!

    Equate this with the following scenario.


    GM decides that one day (AU*), it will come to your house, and change your car, so that the Engine space under the hood, is now twice as


    Now, you have to get your Garage door modified, to fit the new engine, even though you don’t need, or want the extra width.***

    Finally, you hear from GM, that this was on purpose, to help stop criminals from hiding stuff under your hood.****

    * AU = Automatic Updates.

    ** Min width change.

    *** Web Developers.

    **** Completely irrelivant security FUD.


  27. Steve says:

    To vote for the minimum popup window width bug, follow this link:



  28. Alex Lein says:


    The ie team posts that they are becoming more conformant to standards and/or other browsers.. and they are flamed for changing behaviour.

    The ie team posts that they aren’t changing something, and they get flamed for not being standards compliant… and "I’m going back to Firefox".

    I’m amazed you still post anything at all.

    Good on ya for changing the dialog, I think it makes more sense the new way.

  29. Robin says:

    The only sleep functionality in IE is also broken:

    function sleep(timeout)


    window.showModalDialog("javascript:document.writeln(‘window.setTimeout(function () { window.close(); }, " + timeout + "); ‘);");


    In IE6 the modal dialog was invisible, in IE7 you will see the border of the dialog 🙁 .

    So please let the "Window Restrictions Setting" also be aplied on the windows opened by showModalDialog (so I can hide it (again)) or don’t render the dialog (as in IE6).

  30. rsonn says:

    OK… SO then please implement resizeTo() for modal dialogs so that we can set the CONTENT HEIGTH to something smalled than 150px like we can in regular windows. I don’t care if width is limited (I really do but I’ll fight that battle later) but I need to make some Modals less tall to simulate as best as I can Alert dialogs (I can’t use ajax-like DIVs in some cases because they will open in other small windows and they will be clipped.)

  31. rsonn says:

    OK… SO then please implement resizeTo() for modal dialogs so that we can set the CONTENT HEIGTH to something smalled than 150px like we can in regular windows. I don’t care if width is limited (I really do but I’ll fight that battle later) but I need to make some Modals less tall to simulate as best as I can Alert dialogs (I can’t use ajax-like DIVs in some cases because they will open in other small windows and they will be clipped.)

  32. Milo says:

    Hooray for things getting better.  Screw backwards compatibility.  Coding a workaround is infinitely better if it can come with a comment that says: "This is just to support old browsers.  Once nobody uses them anymore, you can rip this out and everything will make sense, forever."

  33. bozo says:

    The part about specifying only the content size is ingeneral a good thing BUT THIS IS NOT A STANDARDS issue since this is not a standards API that we are talking about. This is the dialogWidth/dialogHeight property and the other window properties/api’s are ignored (ie can call resizeTo() on a modal dialog.) But that said I think it is better to specify the content size so that in the future we can ignore chrome calculations.

    The part this is not OK is the wider minimum width/heights. If you look at the common usages for modal dialogs they are often for things that are small and not for displaying large web pages in.

  34. Brett Merkey says:


    In the process of testing the code above in RC1, I got very frustrated for a long while — until I noticed that the Microsoft coders were using "smart quotes."

    Words fail me — which is good because otherwise I could get abusive. I think posting code in a form that proves you did not test it yourselves is a bit amateurish.

    Brett Merkey


  35. EricLaw [MSFT] says:

    @Brett Merkey: Sorry for the inconvenience.  The idea that the code wasn’t tested is mistaken, however.  The quotes were broken by a production process when moving the sample to the blog.  Unfortunately, this happens from time to time.

  36. Brett Merkey says:


    The quotes are still not fixed and the last scripts are still broken. Less effort on excuses and more on fixing. I wish I had such a luxury of excuses allowing me to wash my hands as I release my code to production.

    Brett Merkey


  37. Mary Lou says:

    The new window that is required to be opened for Yahoo Market Tracker either will not open or will open blank. This is a service that is paid for and we do want to be able to use IE7 but sitll be able to use the finance Market Tracker. Help! Thanks.

  38. philip andrew says:

    Specifically you broke my dialogs in my intranet application as each window was sized exactly to fix the entire screen for a fixed screen size.

    Now when the users use IE7, the bottom of the html area is outside of the actual screen area so some of the buttons are now hidden!!!

    The blame comes directly back to us, not to Microsoft.

    Do you understand?

  39. IEBlog says:

    This is just a follow up to my recent post about dialog sizing in IE7. Based on your feedback regarding…

Skip to main content