112578 - search mails window : search subfolders should remember last state

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Brian S. Craigie]

When you click the advanced search, or choose Search Messages... from the Search
menu, the "search subfolders" tickbox is always on by default.  I think it would
be more helpful if this were either:
- off by default
- or made a preference option somewhere
- or remembered if you turn it off for the next time.

When you've got 20000 emails in 100 subfolders of the inbox, searching the
subfolders takes quite some time, and I always forget to turn the darned tick off.

Comment 1

[laurel]

Our spec calls for search subfolders to be on by default and also that's the way
it was in 4.x.  I, for one, like it on by default.

Comment 2

[scottputterman]

I'm going to mark this Wontfix. I've cc'd Jennifer in case she disagrees with that.

Comment 3

[jglick]

I agree.

Comment 4

[Brian S. Craigie]

I don't.  You won't even consider my suggestion to remember the state it was the
last time the window was opened?  By all means default it to on by default when
the browser starts, but please let it remember the state of the tick box at
least until I close the browser?

I was not given any input to the spec, but if anyone had asked me, I would have
asked for this at the time.

Comment 5

[scottputterman]

You're right.  I didn't see your third point.  I agree that that could be a
reasonable thing to do.  So, I'm changing the summary.  But, I'm moving it to
the future milestone.

Comment 6

[Peter Lockhart]

Never mind large folders, the problem is when on IMAP this option is impractical
especially when on a slow link. Unchecking it each time is pretty irritating

Comment 7

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Brian S. Craigie]

I originally submitted the report, but my email address has changed since then and I can't change anything now.  However, the problem still exists, not sure about SeaMonkey (does it still exist?), but it does still happen with the mainstream Mozilla Thunderbird version 2.0.0.21 (20090302).  I would still like it to remember the last state of the tickbox as per the accepted option from Comment 5.

Brian

Comment 10

[Onno Ekker [:nONoNonO UTC+1]]

Thunderbird has this. Compare
http://mxr.mozilla.org/comm-central/source/mail/base/content/SearchDialog.xul#92
http://mxr.mozilla.org/comm-central/source/suite/mailnews/search/SearchDialog.xul#89
Only need to add persist="true" to that line...

Comment 11

[Tony Mechelynck [:tonymec]]

Attachment: patch v0

If it's that simple, I suppose it qualifies as a Good First Bug.

Here's a first attempt at a patch. Two caveats though:
- My specialty is porting one-liners, not XUL programming
- I cannot test that it works, because I'm on Linux, where SeaMonkey trunk building is currently broken.

Comment 12

[Tony Mechelynck [:tonymec]]

Already a month (plus a few hours) with no answer.

If there are reasons external to this bug which prevent reviewing, I can accept it, but I'd like to know. Also, if this bug must wait on a different bug (such as builders going back to green) please add the appropriate dependency.

I prefer even a negative review to this deadly silence. At least with an r- I know what must still be fixed.

Ian: ping?

Comment 13

[Ian Neal]

(In reply to Tony Mechelynck [:tonymec] from comment #12)
> Already a month (plus a few hours) with no answer.
> 
> If there are reasons external to this bug which prevent reviewing, I can
> accept it, but I'd like to know. Also, if this bug must wait on a different
> bug (such as builders going back to green) please add the appropriate
> dependency.
> 
> I prefer even a negative review to this deadly silence. At least with an r-
> I know what must still be fixed.
> 
> Ian: ping?

Sorry, been busy with work.
Are you expecting the setting to persist over a restart of the application or just within the current session?
It doesn't do the former but it does do the latter.

Comment 14

[Tony Mechelynck [:tonymec]]

(In reply to Ian Neal from comment #13)
> (In reply to Tony Mechelynck [:tonymec] from comment #12)
> > Already a month (plus a few hours) with no answer.
> > 
> > If there are reasons external to this bug which prevent reviewing, I can
> > accept it, but I'd like to know. Also, if this bug must wait on a different
> > bug (such as builders going back to green) please add the appropriate
> > dependency.
> > 
> > I prefer even a negative review to this deadly silence. At least with an r-
> > I know what must still be fixed.
> > 
> > Ian: ping?
> 
> Sorry, been busy with work.
> Are you expecting the setting to persist over a restart of the application
> or just within the current session?
> It doesn't do the former but it does do the latter.

Wayne: according to comment #10 the equivalent bug is FIXED, or at least WORKSFORME, on Thunderbird. Does the Tb setting persist session-only or over-restart? And if it is over-restart, do you have an idea of what I missed when I made this one-liner patch?

Comment 15

[Wayne Mery (:wsmwk)]

In TB26beta it persists across startup.

Comment 16

[Tony Mechelynck [:tonymec]]

Comment on attachment 819430 [details] [diff] [review]
patch v0

(In reply to Wayne Mery (:wsmwk) from comment #15)
> In TB26beta it persists across startup.

Thanks Wayne. So the current patch is maybe a first start but not good enough. I'm canceling review requests but not yet obsoleting the patch because I have nothing better so far.

I'm not (yet) throwing hands up in despair but I will have to bone up on the language (XUL, as a start, and maybe also JS and how they interact). I'll try to search MDN (which was much more "searchable" when it was still on Wikimedia software :-( ). I have some ideas of where to search but not much yet.

Comment 17

[Tony Mechelynck [:tonymec]]

Hoho! https://developer.mozilla.org/en-US/docs/XUL/Attribute/persist says:

> Persistence will not remember the absence of an attribute, so for boolean
> attributes like checked where absence means false, you will need to explicitly
> set the attribute to false before the window closes (bug 15232).

However, MXR shows me that checkbox described in XUL and gotten in JS — by document.getElementById("checkSearchSubFolders").checked — but the only place where I see it removed in the code is somewhere under mozmill. It's "disabled" attribute is recomputed in the very last function in suite/mailnews/search/SearchDialog.js (called from two places) but not in mail/ and the "checked" attribute is never changed AFAICT. So there must be a "standard" behaviour when checking a checkbox… and DOM Inspector tells me… that unchecking it removes the "checked" attribute, does not set it to false.

Also: https://developer.mozilla.org/en-US/docs/XUL/Attribute/checked says:

> Use hasAttribute() to determine whether this attribute is set instead of
> getAttribute().

Time for bed. I still wonder how (and where) Thunderbird makes the value persist across startup.

Comment 18

[Tony Mechelynck [:tonymec]]

Don't know if relevant, but a patch (not yet r+) in bug 943096 removes that UpdateSubFolders function which is absent from Thunderbird.

Comment 19

[Tony Mechelynck [:tonymec]]

I'm giving this back to nobody@, it's harder than I thought. Anyone wants to have a try, go ahead. The current patch should be regarded as a WIP.

See also comment #13 and comment #15

Comment 20

[Onno Ekker [:nONoNonO UTC+1]]

I don't quite understand why you have to explicitly persist the value false. If the value is false, it isn't saved. So if you initialize it to false after a (re)start it gets the value you want, or doesn't it?

Comment 21

[Onno Ekker [:nONoNonO UTC+1]]

Oops. Sorry. Just read bug 15232, so now I understand that the value isn't removed from the localstore.rdf, so after a restart it always gets the value true again if you don't save the value false.