Open Bug 112578 Opened 19 years ago Updated 7 years ago
search mails window : search subfolders should remember last state
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.
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.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm going to mark this Wontfix. I've cc'd Jennifer in case she disagrees with that.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
Status: REOPENED → ASSIGNED
Summary: search mails window : search subfolders should be off by default → search mails window : search subfolders should remember last state
Target Milestone: --- → Future
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
Assignee: naving → sspitzer
Status: ASSIGNED → NEW
Component: MailNews: Search → MailNews: Message Display
QA Contact: laurel → search
Assignee: mail → nobody
QA Contact: search → message-display
Target Milestone: Future → ---
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
Status: NEW → UNCONFIRMED
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 22.214.171.124 (20090302). I would still like it to remember the last state of the tickbox as per the accepted option from Comment 5. Brian
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...
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.
OS: Windows 2000 → All
Hardware: x86 → All
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?
(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.
Flags: needinfo?(iann_bugzilla) → needinfo?(antoine.mechelynck)
(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?
Flags: needinfo?(antoine.mechelynck) → needinfo?(vseerror)
In TB26beta it persists across startup.
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.
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.
Don't know if relevant, but a patch (not yet r+) in bug 943096 removes that UpdateSubFolders function which is absent from Thunderbird.
See Also: → 943096
See Also: 943096 →
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
Assignee: antoine.mechelynck → nobody
Status: ASSIGNED → NEW
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?
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.
You need to log in before you can comment on or make changes to this bug.