if you open the preferences window, resizing or maximizing it results in a huge window that contains exactly what was on the screen before - that is, nothing is refreshed, and the upper left hand corner contains everything in the prefs window that was there before. expected result is probably that you cannot resize or maximize the prefs window as is the case in nav 4.51.

Re-assigned to mcmullen@netscape.com, set target milestone to M7, changed platform and OS to All. I guess the right way to fix this is to not allow the window to be resized.

Yes, the prefs window should not be resizable. We need to be able to create windows of different kinds, but currently you can have any kind of window, as long as (to paraphrase Henry Ford) it's modeless, resizeable with a closebox. <window canresize="no" behavior="modal" dialogframe = "yes" closebox = "no" zoombox = "no" width=512 height = 320> </window> Reassigning to trudelle. Changing the summary to "prefs window should not be resizable." Was "when preferences window is resized window is not refreshed"

changing component to xptoolkit, reassigning to danm as p2 for m6

I like resizable dialogs as long as the content reflows properly. I've hacked my PrefsWindow.html to make things resize in a fairly sensible way (attached to bug #4911). This can be useful, especially when you want to make a modal window smaller so you can see some other thing.

Given that you can perhaps design a prefs window whose contents take better to being resized, you should still be able to specify a dialog lacking a resize widget. This is on my M9 task list, so off this bug goes to M9.

*** Bug 6455 has been marked as a duplicate of this bug. ***

I've posted a question regarding resizable dialog issues, including this on the xpfe newsgroup.

Any problems with dialogs that don't take too well with being resized should be bugs I would imagine. What bugs numbers are the relevant ones here?

I've submitted bug #15421, which is a request for whether a window is resizable to be automatically computed based on content.

mass-moving all m12 bugs to m13

I just reported bug #18079 and I was pointed to this bug. I just can't believe what I am reading here. Of course the window should be resizable. When a windows is resized, its components should be processed by the layout algo again so that the position of the widgets is in terms of the main window size. This is GUI design 101. How can anyone seriously argue that dialogs should be fixed in size? That is Microsoft style programming at its worst.

agreeing with the last comment here. pref window resizes fine now, that's a good ui. Stealing bug and marking worksforme.

Bug #17083 is still sitting around on this issue.

*** Bug 17083 has been marked as a duplicate of this bug. ***

h'm, the Prefs on MacOS is not resizable, yet on windows and linux it is resizable. after reading mcafee's last comment, i'll verify this one --but open another specifically for mac... since i don't if Prefs resizability is an option on that platform.

I'm not sure if this is the right bug, bug given some of the comments (esp #11 and #12) it seems like it. In current builds (I'm using 2002-0226-03) on Win2K, the prefs dialog is *not* resizable. Should I file a new bug?