68941 - Browser window opens by default non-maximized at (212;43)

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[Erich 'Ricky' Iseli]

New profile sets the browser window to open by default non-maximized, with left
top corner at x=212, y=43. Which is not good on an 800x600 resolution (part of
the browser is off the screen and it has to be moved in order to be viewable
entirely). Seen on 2001021417 0.8 branch build.

Comment 1

[Peter Trudelle]

Sounds like xpapps, but giving danm first crack at it.

Comment 2

[Peter Trudelle]

->moz0.9.1

Comment 3

[Matthew T (active 1999-2002)]

The equivalent bug for the mail three-pane window is bug 80511.

See also bug 53506 (which this bug is not a dup of).

Comment 4

[Håkan Waara]

Mpt, if you provide the proper coordinates for default placement and sizing 
that should be, I can fix it.

Comment 5

[Dan M]

Matthew isn't complaining that the default coordinates are wrong; more like we 
assume lots of screen space and don't scale well to 800x600.

Comment 6

[Matthew T (active 1999-2002)]

... Or to 640*480.

> Mpt, if you provide the proper coordinates for default placement and sizing
> that should be, I can fix it.

Before I can answer that, I need to know three things from danm:
(1) Are we yet able to specify coordinates relative to the right edge or bottom
    edge of the screen (as you can in standard X geometry, for example)? If
    not, what is the bug number for that?
(2) Does the top left coordinate mean the top left corner of the window chrome,
    or the top left corner of the content inside the chrome?
(3) Is the top left coordinate relative to the screen as a whole, or to the
    part of the screen not covered by the Mac's menu bar?

Comment 7

[Dan M]

The Right Thing to Do is to shrink freshly opened windows to fit the available 
screen real estate. I mean, what sort of dumb program opens user windows 
offscreen, under any circumstances? We have similar code in there already: it 
constrains the position but not the size. Sometimes it doesn't take the size into 
account when constraining position, and it doesn't constrain size itself. This 
code just needs some fairly straightforward tweaking.

PS (1) nope. And that would be a large, recent bug number when it's filed. It 
won't get much priority, though, because we're getting along fine without it so 
far. (2) We use screen coordinates where (0,0) is just below the menubar, and 
windows are placed using the top left outside edge of the window border. XP 
compatibility, and all that.

Comment 8

[Matthew T (active 1999-2002)]

Dan, I think (1) *is* how you'd shrink freshly opened windows to fit the
available screen real estate. It's the simplest method I can think of for doing
it, anyway.

Until then, I would suggest placement at 4,4 (assuming coordinates start at
0,0), with dimensions of 610*450. This (if my arithmetic is correct) would fit
snugly in a 640*480 display, with a 4-pixel margin around each side as is
customary on Mac OS for clicking through to the Finder. (At 640*480 you're
unlikely to care about leaving a column of desktop icons visible, but when (1)
is implemented we should do that.) On a higher resolution it would be easy to
enlarge this small window to a suitable size; but at 640*480 it would be very
awkward to shrink a larger window to a suitable size.

On Windows there is no particular reason to have that 4-pixel margin (since
focusing the desktop doesn't gain you much), but there is no particular reason
not to have it either. And the Windows taskbar is about as high as the Mac menu
bar. So the same dimensions should work just as well there, I think. Maybe Håkan
can try it out and see. :-)

Comment 9

[Matthew T (active 1999-2002)]

Uh, make that dimensions of 632*450, not 610*450. (It was a typo. Honest.)

Comment 10

[Andrew Simmonds]

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

Comment 11

[Håkan Waara]

I got a screenshot ready, with mpt's suggested coordinates incorporated. Coming 
right up.

Comment 12

[Håkan Waara]

Attachment: how it looks on a 1024x678 display with mpt's suggested coordinates

Comment 13

[Håkan Waara]

I tried it in 640x480 mode and it worked well, much better than before!

Requesting r= and sr=.

Comment 14

[Håkan Waara]

Attachment: fix for this and bug 80511

Comment 15

[Håkan Waara]

If you r= or sr= this, then please take a look at the part of the patch which
fixes the initial 3pane placement/sizing and note it in bug 80511.  Thanks!

Comment 16

[Andrew Simmonds]

although this is way better than before wouldnt it be even better if there was 
some code put into place that put a window of dimentions 90% of screen size in 
the center of the screen?

Comment 17

[Håkan Waara]

Andrew, no.

Comment 18

[Dan M]

Andrew, Håkan: I'd say if you want a window that large, you should just maximize 
it. But Andrew's comment recalls my comments above. It seems there are at least 
two active interpretations of what this bug means. I'll have to open a new bug to 
track the effort to shrink a window that tries to open itself too large for the 
screen, for whatever reason. Given that this bug is now firmly all about the 
current silly initial size and position, r=danm on the above patch.

Comment 19

[Håkan Waara]

Thanks Dan!

cc alecf for sr=.

Comment 20

[Alec Flett]

sr=alecf

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

a=dbaron for trunk checkin

Comment 22

[Håkan Waara]

fix checked in.

Comment 23

[John Morrison]

fixed in mozilla builds. Netscape defaults are (aaargh!) a matter for 
http://bugscape.netscape.com/show_bug.cgi?id=6898