IE7 Dialog Sizes – A Quick Update

This is just a follow up to my recent post about dialog sizing in IE7. Based on your feedback regarding the minimum dialog height restrictions, my team re-evaluated our position and changed the minimum height from 150 to 100 pixels. We think this change:

  • Reduces application compatibility issues where dialogs were coded to the IE6 minimum height
  • Is more consistent with other browsers’ minimum height providing more consistency for content developers

Again, we appreciate your constructive feedback. Keep it coming.


Comments (18)

  1. Anonymous says:

    there are very error in ie7 🙁

  2. Steve says:

    Ok, but what about the width!!!!!

    The new width is like ~240px!!!! this is the issue, not (so much) the height.

  3. Steve says:

    Oh, and if getting this bug fixed, is dependent on votes, please vote for this bug here.

  4. Steve says:

    Oh, and while on the subject, can the maintainers/editors of the IE Feedback site please stop the charade!

    Please do not close off bugs, that are still active, with lines like: "Have you tried seeing if this bug still exists in {{insert_latest_build}}?"

    Not only is this extremely anoying, but very inconsiderate to the people that are submitting these bugs to you.

    One glance at the subject, or description should be enough for anyone on the development team to be able to judge if this is a fixed issue or not.


    (PS, this reads as: Please do not re-close all the open bugs when RC2 comes out… if the developers fixed something, then have them go in, and close the targeted bugs _only_)

  5. Not mentioned yet (did not find it in Search) …

    If I rightclick on a picture and then "Save Picture As …" IE7 wants to save it as untitled.bmp

    If I rightclick on the same picture and "Properties" the name (NameOfPicture.jpg) appears as it should

  6. russ says:

    This is great and i very much agree with the comment about the minimal width. Can we please get that changed back as well. Both are bit issues for different reasons. Hieght is an issue for things like confirm dialogs with HTML requirements. Width is an issue for some widgets like date pickers that just look bad being forced to be so wide.

  7. Petknep [MSFT] says:

    @Ralph G. Roeske

    You might be hitting the corrupt cache issue:

    If not please give me a site repro so we can investigate it.

  8. Tino Zijdel says:

    Ralph: empty your cache, hit F5 and try again. I do find it hard to swallow though that this bug still seems to be present in IE7 – but then again many bugs still are…

  9. EricLaw [MSFT] says:

    Most of the root issues where SaveAs only offers BMP have been fixed for IE7, but there are still a few instances (specifically, when the server prohibits caching) where IE only has the in-memory representation (bitmap) to offer.  If you can provide repro URLs, we can determine if that’s the problem you’re hitting.

    We’ll be looking at that for a future version of IE.

  10. Tino Zijdel says:

    EricLaw: good to hear that you did look into it for IE7. I however do think that in the case where a server dictates no-caching IE7 simply should re-request the image for save-as instead of offering the in-memory bitmap, but I guess that’s exactly what you’re getting at mentioning future versions of IE.

    sorry for the off-topic post

  11. David Wrixon says:

    Do trvialities like this really warrant consideration of a RC2? This is the sort of stuff that should be corrected during Auto Updates. Those that are not switched on enough to use Auto Updates are hardly going to get excited about phaff like this.

  12. Charles Bocock says:

    Totally unrelated, but something I’ve just hit.

    IE7 doesn’t appear to support "border-spacing" CSS property for tables, yet it has removed a nasty hack ("border-spacing: expression(cellSpacing=20);") that allowed CSS styling of table cell margins in IE6.

    Do we really have to drop back to HTML (cellspacing attribute) to style cells in IE?

  13. Brutus says:

    This is unrelated but I was reading slashdot and a question came up concerning IE7’s "protected mode".  

    Particularly, the documentation here:

    says that IE7’s "protected mode" is "Available only to users running Internet Explorer 7 in Windows Vista Enterprise".  It says this both in the "Introduction" paragraph and the sidebar.

    I thought protected mode was used by IE7 in *all* versions of Vista, not just Vista Enterprise.  What’s the deal here?  Please tell me that this is a documentation error, and if so, correct it ASAP.  You guys can’t be so foolish as to only implement protected mode for Vista Enterprise (which is the version least likely to even need it).

  14. Brutus,

    You are correct Protecte Mode is in all versions of Vista not just Vista Enterprise. I think the article you are referring to is targetted at the enterprise and got it a little wrong in that particular line. I’ll see that we have it corrected.



  15. Paul Clarkin says:

    I also would like to voice that reducing the width enforcement is desired too.

    It is a shame when quite a nice product is ruined by stupid development decisions like this.

    I have voted in the feedback site.

  16. Steve says:

    Hello all Developers!

    Unfortunately, this bug will _NOT_ be resolved, although most of us will shake our heads in disbelief, this looks like it will never be fixed, not even in IE8.

    Quote from the bug, in IE Feedback… where [MSFT] Travis replies:

    "The revision of the minimum height and width values in IE7 are very intensional. When the height and width were questioned on the blog, we re-evaluated out position on height, because the change from 100 to 150 was unsubstantiated and not based on any real-world scenario or justification. However, that was NOT the case for width.

    IE7 builds from one codebase on winXP and Vista. Windows Vista adds a new important security measure known as "Protected Mode" (as you probably know). The current "status" of the protected mode feature was determined to be placed on the status bar. As this is an important security notification to the user, the user-experience team, in conjunction with my team, decided that as part of a dialog or popup, this information MUST be visible.

    As a window shrinks horizontally, you’ll notice that certain status bar elements shrink to a certain point, then get truncated. Within the primary IE frame, we have [status notification area][various icon notifications][Zone information (security)][Zoom]. When we drag the window as small as it will go, everything but the [Zone information (security)] and [Zoom] will be hidden. Zoom is an important feature–it has to stay. Zone info is security and has to stay. The zone information as has the protected mode text on it and will read (depending on zone) "Internet | Protected Mode: On". As you can see that text is much larger than 100 pixels.

    To accomodate the extra length there, and to make sure that more of the address bar is visible (but this wasn’t as important as the status bar), we decided on a round 250 pixels.

    I’m sorry, but this design change will not be reverted.


  17. Paul Clarkin says:

    But what if you are running in a trusted zone, in which the "allow popups to run without status bar or address bar" setting is set?

    Then it just looks stupid.

    Maybe, in that event, allow the window to be sized as the _Trusted_ developer intended?

  18. IEBlog says:

    Hi, Travis here, a program manager for Trident/OM. In Beta3, you may have noticed that modal or modeless