99264 - "Search Messages" and "Search Addresses" windows should remember Size & Position

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Peter Lairo]

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

"Search Messages" Window should remember size & Position

The default size of the "Search Messages" window is too small. Therefore I
always increase its size (height & width). It is very annoying to have to do
this every time. Therefore, Mozilla should remember the size & position the user
chose.

RELATED: The separator between the search criteria and the search results below
should remember where the user last placed it. Most of the time the user will
want one or max two search criteria, and the default (and remembered) position
should respect this logic - i.e., the bar should be much higher than it is now.

ALMOST RELATED: The position of the separator in the address book should also be
remembered across sessions. The current default is very bad (too high) since the
user will usually want to see as many addresses as possible. Therefore the
default should be much lower, and it should remember where the user last put it.

Comment 1

[Håkan Waara]

Seeing the splitter and window problems here too.

Comment 2

[Navin Gupta]

over to seth

Comment 3

[laurel]

still exists dec14 commercial trunk

Comment 4

[Stefan Borggraefe]

Taking.

Comment 5

[Stefan Borggraefe]

The "Search Addresses" window has the exact same problems and the fix for both
windows is the same. So I'll fix it via this bug, too.

Comment 6

[Stefan Borggraefe]

Attachment: Fix.

This patch changes the following:
- the window-size and -position are saved
- the position of the splitter is remembered, too
- there is now some more place for the search results compared to the search
terms in the initial window layout

Comment 7

[[e-mail]]

Comment on attachment 131869 [details] [diff] [review]
Fix.

You have to be careful when persisting splitters; I know two ways which always
work:
1. Flex and persist both boxes. This makes both panes expand when the window is
resized, but also makes the splitter restore to the same place when the window
next opens.
2. Only flex the second box. Persist the first box. Define an initial size for
the first box. Apply resizeafter="grow" to the splitter. In this case the first
box always remembers its size.

Comment 8

[Stefan Borggraefe]

Attachment: Updated patch

Addressed Neil's comments. I used his first suggestion.

Comment 9

[Peter Lairo]

> I used his first suggestion.

That is unfortunate, because:

1. When there are two panes, one of them is likely to contain information that
lends itself to a fixed size. The Search Criteria is an excellent example of
this: users are likely to have no more than 1-3 search criteria. The
addressbook's address preview pane (bottom) is another good example where a
fixed pane size during window resize is preferable.

3. The user is more likely to resize *after* the search results come pouring in
in order to see the usually longish list of results. He will therefore want the
results pane (bottom) to get bigger, and not care about the search criteria pane
(top).

3. It doesn't remember the user-selected position of the splitter. The same
logic as applies to window size/position (this bug) also applies to the
splitter:  Set a meaningful default, and remember where the user prefers it to
be after that.

I hope you will reconsider and use Neil's second suggestion.

Of course, as always, I may be overlooking something obvious or important. ;)

Comment 10

[Stefan Borggraefe]

Peter: I think you are right. It would be better when only the result-area would
grow when you resize the window. For the same reason the splitter should be
changed from collapse="after" to collapse="before". I hope the reviewers will
agree when I include that change in this bug, too.

Your third point isn't true. With the patch I uploaded the splitter position is
remembered. At least it works for me. Have you tested the patch?

Anyway, I'll upload an updated patch today.

Comment 11

[Stefan Borggraefe]

Attachment: New patch

Now only the result pane changes its size when the window is resized (for the
valid reasons Peter Lairo stated). For the same reasons I changed the behaviour
of the splitter from collapse="after" to collapse="before".

After some comments from timeless on IRC yesterday I changed the unit for the
default sizes from pixel to em. This way thoses sizes are adaptive to the font
size.

I didn't add resizeafter="grow" to the splitter, because this looked broken to
me: When it is added it is possible to move the splitter out of the visible
area of the window. The persistence of the splitter position works without it
anyway.

Comment 12

[Peter Lairo]

> Your third point isn't true. ("doesn't remember the user-selected position of
the splitter.")

Then I must have misunderstood Neil's statement in comment 7: "makes the
splitter restore to the same place when the window next opens."

Anyhoo, GREAT work Stefan. Thanks for the fix. :)

Comment 13

[[e-mail]]

Comment on attachment 131888 [details] [diff] [review]
Updated patch

r=me but I think you should persist sizemode as well.

Comment 14

[[e-mail]]

Comment on attachment 131946 [details] [diff] [review]
New patch

Sorry, I don't like the collapsing effect.

Comment 15

[Stefan Borggraefe]

Attachment: Update of the "Updated patch"

Neil: This is the patch you already gave r+, but with the change from pixel to
em and the persistence of sizemode added.

Peter: Neil likes prefers the other patch. So I go with it in order to get the
necessary review. It cleary fixes this bug and the behaviour of the splitter
isn't altered other than its position is saved.
If you want the splitter to be changed in other ways you may file another bug
where this issue could be discussed.
I want to use this bug to get the changes into the tree necessary to handle the
window size & position properly since this doesn't seem to need any discussion
and I really need this with my 2048x1536 desktop resolution. ;-)

Comment 16

[[e-mail]]

Comment on attachment 131961 [details] [diff] [review]
Update of the "Updated patch"

>+        style="width: 52em; height: 36em"
Nit: ; after each style, not just between styles

>+    <vbox id="searchTerms" flex="3" style="height: 10em" persist="height">
I don't think adding style here is right.

Same for the other window, of course.

Comment 17

[Stefan Borggraefe]

Attachment: Addresses Neil's comments

I removed the style attribute from the <vbox> and added the semicolon.
Otherwise unchanged.

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

cvs commit: Examining mailnews/base/search/resources/content
Checking in mailnews/base/search/resources/content/ABSearchDialog.xul;
/cvsroot/mozilla/mailnews/base/search/resources/content/ABSearchDialog.xul,v  <-
-  ABSearchDialog.xul
new revision: 1.9; previous revision: 1.8
done
Checking in mailnews/base/search/resources/content/SearchDialog.xul;
/cvsroot/mozilla/mailnews/base/search/resources/content/SearchDialog.xul,v  <--
 SearchDialog.xul
new revision: 1.75; previous revision: 1.74
done

Comment 19

[Stefan Borggraefe]

Comment on attachment 131975 [details] [diff] [review]
Addresses Neil's comments

Requesting approval for 1.5.

This is a nice usability enhancement, because you only have to resize these
windows to your preferred size once. Very low risk since only two XUL files are
chnged.

Comment 20

[Asa Dotzler [:asa]]

Comment on attachment 131975 [details] [diff] [review]
Addresses Neil's comments

too late for 1.5.