Apprunner (tues, mar 18 nightly build) is not adjusting itself to the screensize that you are using. Currently it almost works at 800-600 but seems to want to be on a monitor that is 800-620 or so. This causes part of the bottom bar and the new components on the bottom to be hidden. With this, a scroll bar appears that shifts the window and the toolbars around so that you can access the hidden area. If the window is resize to a larger res, there is a large grey area at the bottom of the screen.

Re-assinged to trudelle@netscape.com and changed component to XUL. Peter, Eric and David have fixed this, right?

This sounds like at least three bugs. One is that the window should resize itself automatically to fit on a smaller display. I think that's a Window Manager issue. The second, having nested scrollbars, is a known Gecko problem. The third, a fat status bar, should be fixed by the box widget. From the summary, I think this report describes the first problem, and should go to davidm. Can we get someone in QA to ensure that the other two problems have separate bug reports?

reassigning to hyatt as p3 for m4

gerardok (or get someone if you are working on Test Harness), can you check this out and split into separate bugs if necessary. Thanks!

jan, i'm investigating and splitting this bug up right now...

ok. see bugs: 4149 - fixed status bar 4150 - nested scrollbars this bug becomes crossplatform, because it happens on RedHat 5.2 March 22 1999 MacOS 8.51 March 22 1999 Winnt 4.0 March 22 1999

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

While XUL may eventually address this the problem arises from the following 2 lines in nsAppRunner.cpp's main: PRInt32 widthVal = 615; PRInt32 heightVal = 650; I've got a hack ready for the Mac (in nsMacWindow.cpp) that pins the height of the bottom of the window to the bottom of the grayregion. I want to talk to hyatt about it before I check it in.

What's the holdup on this?

The hack to fix this on Mac is checked in, what we need is a true XP fix which I believe is the window manager that David Matiskella in the XPApps is working on.

I'm reluctant to check in a hack for this simply to meet a milestone. I don't think the right fix for this bug is going to make it into M4, and it's a waste of time to produce throwaway code for the milestone.

Let's just shrink the height value. 650 is ridiculously tall. I'll shrink it to 480, and check in the revision.

I have decreased the height to 480 for all new windows and checked it in. Moving to M5 and reassigning to Don, so he can give it to the owner of the window manager.

Re-assigned to davidm; changed component to XPApps and milestone to M6.

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

Not gonna happen for m6 since the screen object is not done

This is really part of David windows tiling feature work. Move to M11.

when this does get fixed and the fixed size hack is removed what exactly should happen when a new window(and the first) window is opened? I'm asking now cuz it's going to be more difficult to remember what this is all about a cople more months from now. So if we can state the expectations clearly now it'll be easier to test and verify :-)

adding depends.

m13 due to dependency. The fix is uncommenting 1 line of js.

Fix checked in. On the mac if you make a huge window, quit the app, reduce the resoultion to 640*480 and launch the app again the window scales to fit the screen.

using the 2000011910 build if I open the browser and maximize the window. then open a new window (different bug) then quit the browser and shrink my resolution, when i relaunch the browser the window is way too big for my screen. reopening.

yep the fix was back out since it conflict with something else that was checked in. I have been told we want to do this in native code. Reassign to danm

Clearing FIXED resolution due to reopen.

*** This bug has been marked as a duplicate of 26834 ***

VERIFY dupe