130872 - Always create new windows within screen boundaries

Status: VERIFIED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[derek fong]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9) Gecko/20020310
BuildID:    2002031005

When working with large browser windows, creating a new window in Mozilla will
result in the new window being positioned such that the edges of the window
(usually the bottom and the right edge of it) are positioned off-screen.  This
means that the status indicators and Mozilla icons are hidden and sometimes even
the scrollbar itself.  This, in turn, means that users have to always manually
drag the new window closer to the top of the screen in order to see the whole
window.


Reproducible: Always
Steps to Reproduce:
1. Create a large default window size (doesn't have to be maximized, but at
least either of the bottom or right edges of the window should be near one of
the edges of the screen)
2. Create a new window (Cmd-N)
3. The resulting window is placed several pixels down and to the right, but the
same size as that of the previous window, resulting in part of the window not
being visible until the window is moved to expose the missing parts of it

Actual Results:  Certain parts of the window are inaccessible until the window
is manually moved into a better position.

Expected Results:  Either:

1. The new window gets similarly positioned, but its size is made smaller to
make sure that the screen's boundaries are respected, or
2. The new window gets stacked directly on top of the previous window with no
change in size.

Ideally, this would be configurable as a user preference.

Comment 1

[Carl Schrader]

Have you used fullscreen mode? I have noticed this after I use fullscreen. 
Seems to open a new window correctly otherwise.

Comment 2

[derek fong]

I have not used fullscreen mode.  In fact, for testing, I trashed everything in
~/Library/Mozilla and started Mozilla up from scratch and can still reproduce
this problem.

Comment 3

[Greg K.]

Confirmed using FizzillaCFM/2002041712 (RC1). New windows should always be
created entirely within the screen boundaries.

(Also tested BBEdit 6.1.2 and IE 5.1.4 (4415.2), and they did this right,
creating new windows entirely within the screen area.)

Guessing XP Apps: GUI Features.

Comment 4

[Greg K.]

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

Comment 5

[Greg K.]

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

Comment 6

[derek fong]

It would also be nice if Mozilla were Dock-aware so that windows are never
created (or moved) by Mozilla to overlap the Dock if it's visible.

Comment 7

[Greg K.]

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

Comment 8

[Greg K.]

Setting OS to Mac System 9.x per bug 153955.

Comment 9

[Greg K.]

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

Comment 10

[Jesse Ruderman]

See also bug 165467, "New window does not respect Dock position" (Mac OS X,
Chimera).

Comment 11

[lohphat]

I have the same problem on win32.  URL: http://www.sfgate.com/
Cliick on Pic of the Day with the taskbar fixed and always on top on the lft
screen border.  The new window's top left origin is under the taskbar.

Comment 12

[Greg K.]

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

Comment 13

[Greg K.]

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

Comment 14

[Greg K.]

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

Comment 15

[Chris Casciano]

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

Comment 16

[Cyndi Norman]

I just would like to note (though you all probably already know) that this bug
is still present in the latest version of Mozilla for Mac OS 9.*.  Version 1.2.1.

Comment 17

[Greg K.]

Cyndi, Mozilla for Mac OS 9 is no longer being maintained.

Comment 18

[Dan M]

Test with a build made after 8 May 2004, trunk or any branch. This should have
been fixed by bug 239876. (I don't have a Mac, so I can't say for certain.)

Comment 19

[Marc Bejarano]

the problem still exists with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 ID:2006042618

should this bug remain application suite only?

Comment 20

[firefox]

I'd like them to be topaligned and match the previous window size.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2]]

WFM with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4pre) Gecko/20070510 BonEcho/2.0.0.4pre

Anyone who is able to reproduce it with a current 1.8 branch build?

Comment 23

[Marc Bejarano]

this wouldn't be quite so annoying if it weren't for bug 252666.

cc'ing colin barrett per his statement of interest in making firefox on the mac
suck less (http://iamthewalr.us/blog/2007/04/20/firefox-on-the-mac/)

henrik: define current :P

i still see the problem with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 ID:2007030919

Comment 24

[Colin Barrett [:cbarrett]]

I believe this is fixed for Firefox 3. If you could test it and see if you see problems there, that would be great. Thanks :)

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: Half of the toolbar visible after creating a new window

Ok, I have tested again with the dock at the bottom. Maximizing the current window with the mouse to fullscreen (also behind the dock) and creating a new window has following behavior:

Fx 2.0.0.4pre: Window is created staggered and is positioned the same amount of pixels under the dock. But it is within screen boundaries.

Fx 3.0a5pre: Window is not created staggered and not outside screen boundaries. Even it isn't positioned behind the dock. The whole available screen is used.

Mark, can you verify this behavior with a current trunk nightly build please? Is this the expected behavior for you? Also that the new window is not staggered. For 1.8 branch builds it is not ok when you include the dock into the screen boundaries. Fx3 adjusts the height of the window when moving it behind the dock or doesn't let the user increase the height if the window will overlayed by the dock. Moving it behind the dock automatically reduces the actual height. That's what see on Mac OS X 10.4.9 (Intel).

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Oh I forgot, when using a trunk build it could happen that the toolbar is only half-visible and hidden by the title bar. That was caused by the gmail notifier extension. On each new window I got a js error dialog. Removing this extension stops that behavior.

Comment 27

[Marc Bejarano]

i just fired up Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a5pre) Gecko/20070521 Minefield/3.0a5pre ID:2007052104 [cairo] with a basically blank user profile.  with the dock on the left and a window that takes up all vertical real estate, a new browser winder was staggered down and to the left as usual with the status bar off the screen.  behavior has changed from fx 2.x, though.  it used to be that subsequent windows would continue to be opened too low like the second, each further to the right.  now, the third window is back up at the top with visible status bar and then the fourth down too low, again.  this repeats.

Comment 28

[amateur6]

Firefox 2.0.0.14, Mac OS 10.5.2 (non-Intel Mac: g4 power pc) -- still experiencing this bug.

Dock on left side of screen, browser window at full screen height (manually set, not maximized). New window behaviors are as follows:

1) (2nd open window) offset down and to the right. Status bar and the resize corner at the bottom of page are "off the screen".

2) (3rd open window) offset to the right, but no further down.

3) (4th open window) not offset at all from previous window. This continues for all subsequent windows.

It's been more than 5 years on this one, and it seems like a pretty basic behavior. This is identical for me at home and at work, so I doubt it's just isolated cases. Is it some sort of commonly-corrupted file?

Comment 29

[Greg K.]

amateur6, this is fixed in the upcoming Firefox 3. It will likely not be fixed for Firefox 2.

Comment 30

[amateur6]

Thanks Greg -- that's great! It's nice knowing that it WILL be addressed.

Comment 31

[Wayne Mery (:wsmwk)]

(In reply to comment #29)
> amateur6, this is fixed in the upcoming Firefox 3. It will likely not be fixed
> for Firefox 2.

Gone with FF3?

Comment 32

[Marc Bejarano]

i can no longer repro with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8 ID:2009032608

Comment 33

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thanks Marc. Marking this bug as WFM for now. If anyone can still see this behavior feel free to reopen the bug and attach a screenshot and helpful STR. Thanks.