145941 - (RememberPosition) All resizable/movable windows should remember user selected size/position

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Tracking, defect)

Description

[Peter Lairo]

All resizable/movable windows should remember user selected size/position

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0+) Gecko/20020520

This is currently particularly annoying with the "Add Bookmark" window
(Bookmarks / File Bookmark, or CTRL+SHIFT-D) which shows the BM folder list
*much* too short.

Comment 1

[Peter Lairo]

perhaps people could start listing affected windows here. The fix should
(hopefully) be as simple as adding an entry into localstore.rdf for each window.

Comment 2

[Pete Boyd]

adding bug 99860 as a dependency as File Bookmark window size is part of that
bug (problem with this tho is that bug also includes others, but thats the one
duplicates of this problem are duped against)

Comment 3

[Pete Boyd]

adding bug 99264 as dependency ("Search Messages" Window should remember Size &
Position)

Comment 4

[Pete Boyd]

adding bug 65596 as dependency ("View Stored Passwords" window should be wider
and remember previous size)

Comment 5

[Peter Lairo]

Affected Window: *Select Addresses* (Compose -> Options / Select Addresses..)

Comment 6

[Pete Boyd]

(actually adding 65596 dependency as I must have forgotten to type it in)

Comment 7

[Matthias Versen [:Matti]]

-> Bookmarks for the "Add Bookmarks"

File New Bugs for the other Windows in other Areas.
IF you want a tracking bug, file one and assign it to you.

Comment 8

[Matthias Versen [:Matti]]

.

Comment 9

[Peter Lairo]

Ben, you can assign this bug to me if you want, as I am interested in tracking this.

Comment 10

[Michael Lefevre]

just looked into this to find a bug to dupe to...

as comment 2 says, it seems that bug 99860 isn't addressing the size issue of
File Bookmark.  that looks like bug 123207, so i've just duped a new report (bug
147550) against that.

removing dependency on bug 99860 and adding bug 123207... hope that's OK.

Comment 11

[R.K.Aa.]

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

Comment 12

[Peter Lairo]

Adding Keywords: meta, mozilla1.0, adt1.0.1, mozilla1.1, mozilla1.0.1, nsbeta1,
nsbranch, UI, nscatfood
because it is a pain to *constantly* have to resize and move so many dialogues.

[OT] ;)
isn't it nice that mozilla is so far that this is now finally worth griping about? 
[/OT] ;)

Comment 13

[Samir Gehani]

Nav triage team: nsbeta1- (not plussing tracking bugs)

Comment 14

[Wesha]

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

Comment 15

[Ric Fischer]

Confirming for Mozilla 1.1a. When positioning primary window, primary window's
position is shifted down exactly the height of the Windows Taskbar minus one
pixel. Interestingly, subsequent windows retain correct cascading position(s).

Comment 16

[Michael T. Babcock]

w.r.t. Bug 158471 being marked as a duplicate of this bug, please note that Bug
158471 is about primary browser windows in Mozilla, not just dialogs.  If this
feature can be implemented across the board, all the better.  Also note that Bug
158471 was submitted requesting that these 'memories' be made optional (that is,
to not remember the most recent size request, for example).

Comment 17

[Stephen Rasku]

Does fixing this bug mean that if I resize or move a window (say the "File
Bookmark" window) and close it it will re-open at the same location and size
that I closed it last.  Or is there another way select the size and position?

Comment 18

[Peter Lairo]

RE comment #17: Yes. Isn't the subject line clear?

Comment 19

[Jimmy]

I'm using Build 2002101612 on a Win2K system, with the same size/position problem.

Comment 20

[Scott]

I think the same should apply with the preferences window or any user interface
window so that the sizes will be stored and the default size only used if the
user does not choose to stretch the window size.  Also, a setting to ensure that
the window is not sized smaller than the minimal default settings would be
suggested as well.

Comment 21

[Alexander Kogan]

Hello! This bug ist stil there...

Comment 22

[Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat )]

Should this get reprioritized / solved?

Comment 23

[Alex Keybl [:akeybl]]

(In reply to Gregg Lind (User Research - Test Pilot) from comment #22)
> Should this get reprioritized / solved?

Tracking flags are only used for new/critical user issues. The product team is the best group to get in touch with for future prioritization.

Comment 24

[BMO Automation]

Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE.
If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work
being tracked. The Core: Tracking component will no longer be used.