Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 16176 Browser window does not retain its position across quit/restart on Mac OS X
Starred by 3 users Project Member Reported by, Jul 8 2009 Back to list
Status: Verified
Closed: Jul 2009
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment
Chrome Version       :
URLs (if applicable) : N/A
OS version               : 10.5.7
Behavior in Safari 3.x/4.x (if applicable): works, but N/A
Behavior in Firefox 3.x (if applicable): works, but N/A
Behavior in Chrome for Windows: N/A

What steps will reproduce the problem?
1. Run Chrome and open a single browser window
2. Note specifically where the browser window is on the screen
3. Quit Chrome and restart it
[4. Repeat as many times as necessary to move the browser window as far 
as desired]

What is the expected result?

The window should reappear where it had previously been. I believe that in 
the previous version (3.0.190.x) this was the behavior, but I might be 

What happens instead?

The window reappears a small distance (about the height of the menu bar, 
actually) above where it had previously been.
Labels: Mstone-MacBeta
Comment 2 by, Jul 15 2009
I can confirm this bug.

This bug can be easily reproduced by just pressing CMD + W and then CMD + N. Each 
time the new window will move a few pixels closer to the top until it's there and it stops 
Status: Assigned
Comment 4 by, Jul 16 2009
The following revision refers to this bug: 

r20911 | | 2009-07-16 15:34:11 -0700 (Thu, 16 Jul 2009) | 8 lines
Changed paths:

Adds window position save/restore support for multiple monitors on Mac.
Fixes a bug where windows would creep up the screen every time you quit/restarted.

TEST=Windows should save/restore in the correct location, with either a single
monitor or multiple monitors.
Review URL:

Status: Fixed
Status: Verified rev: 21075
 Issue 17123  has been merged into this issue.
Comment 8 by, Jul 20 2009
I can confirm that the latest builds have this issue fixed for one monitor at least. I do 
not have the possibility to test this on a setup with more than one display.
Works well even with secondary display.
Comment 10 by, Jul 20 2009
Then this should be marked as "Fixed", right?
Project Member Comment 11 by, Oct 12 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Sign in to add a comment