Apprunner not resizing according to screensize too big for <=832x624 resolution

VERIFIED DUPLICATE of bug 26834

Status

()

Core
XUL
P2
normal
VERIFIED DUPLICATE of bug 26834
20 years ago
19 years ago

People

(Reporter: Jason Kersey, Assigned: Dan M)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

20 years ago
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.

Updated

20 years ago
Assignee: don → trudelle
Component: Apprunner → XUL

Comment 1

20 years ago
Re-assinged to trudelle@netscape.com and changed component to XUL.

Peter, Eric and David have fixed this, right?

Comment 2

20 years ago
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?

Updated

20 years ago
Assignee: trudelle → hyatt
Target Milestone: M4

Comment 3

20 years ago
reassigning to hyatt as p3 for m4

Updated

20 years ago
QA Contact: 3853 → 4015

Comment 4

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

Comment 5

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

Updated

20 years ago
OS: Windows NT → All
Hardware: PC → All

Comment 6

20 years ago
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

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

20 years ago
QA Contact: 4015 → 4130

Updated

20 years ago
Summary: Apprunner not resizing according to screensize. → Apprunner not resizing according to screensize too big for <=832x624 resolution

Comment 7

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

Comment 8

20 years ago
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.

Comment 9

20 years ago
What's the holdup on this?

Comment 10

20 years ago
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.

Comment 11

20 years ago
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.

Comment 12

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

Updated

20 years ago
Assignee: hyatt → don
Status: ASSIGNED → NEW
Target Milestone: M4 → M5

Comment 13

20 years ago
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.

Updated

19 years ago
Assignee: don → davidm
Component: XUL → XPApps
Target Milestone: M5 → M6

Comment 14

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

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 15

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

Updated

19 years ago
Target Milestone: M6 → M7

Comment 16

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

Updated

19 years ago
Priority: P3 → P2
Target Milestone: M7 → M11

Comment 17

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

Updated

19 years ago
Blocks: 10979

Comment 18

19 years ago
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 :-)

Updated

19 years ago
Depends on: 13392

Comment 19

19 years ago
adding depends.

Updated

19 years ago
Target Milestone: M11 → M13

Comment 20

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

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 21

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → REOPENED

Comment 22

19 years ago
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.

Updated

19 years ago
Assignee: davidm → danm
Status: REOPENED → NEW
Component: XPApps → XP Toolkit/Widgets

Updated

19 years ago
Target Milestone: M13 → M14

Comment 23

19 years ago
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

Updated

19 years ago
Resolution: FIXED → ---

Comment 24

19 years ago
Clearing FIXED resolution due to reopen.
(Assignee)

Updated

19 years ago
Target Milestone: M14 → M16
(Assignee)

Comment 25

19 years ago


*** This bug has been marked as a duplicate of 26834 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → DUPLICATE

Comment 26

19 years ago
VERIFY dupe
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.