106943 - Quick Search tracking bug

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[scottputterman]

Rather than keeping the dependencies under the original Quick Search bug, I'd
like to see 103734 verified as fixed and then keep a list of things we need to
fix under this bug.

Comment 1

[Peter Lairo]

Carrying over some unrealized suggestions from closed bug 103734:

Since the search bar takes up so much space, it would be better to give it some
*more functionality*. 

Assuming the search *hides* all messages that do NOT meet the search criterion: 
-> What if a user wants to see the replies to his posts and therefore filters on
his name (this is what I might use it for most)? Then the user would have to
type his name, highlight one of his posts, remove the filter, read the reply,
reenter his name in the search, highlight his next post, remove the filter ...
repeat ad nauseum.

Therefore, it would be useful to have some buttons in the quicksearch bar:
1. Filter (or "Go"?): hides all messages except those that match the search
criterion (current behaviour?).
2. go next: doesn't hide anything. Jumps to the next message that matches the
filter.
3. go previous: doesn't hide anything. Jumps to the previous message that
matches the filter.

Note: 2 and 3 could just be icon arrows (<-/->) to save space.

Of course Prev. and Next should respect the collumn sort order the user has set.

Comment 2

[Ben Ruppel]

Hi, when I use quicksearch in a threaded message pane view (ie, a newsgroup),
get a result, then delete my search term to restore my view, the thread pane
isn't threaded correctly.  Messages that should be children of some threads
aren't placed back until I click on the threaded/unthreaded view.  Should I file
a separate bug?  Anyone else see this?

Comment 3

[Håkan Waara]

I see a similar bug, if I put in some terms into Quick Search, it doesn't obey
to my sort direction.

Comment 4

[Jaime Rodriguez, Jr.]

what's the target for this feature? what are the chances it will make 0.9.8?

Comment 5

[scottputterman]

the feature landed in 0.9.6.  The dependency bugs are what matter.

Comment 6

[Jaime Rodriguez, Jr.]

are the dependency bugs RFE, bug fixes, or completion of functionality. Maybe,
II should've asked, if this feature will be functioning as designed by 098?

Comment 7

[scottputterman]

There are some bugs we need to fix in 0.9.9.  

Comment 8

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

mass re-assign.

Comment 9

[Robert Kaiser]

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 10

[Robert Kaiser]

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 11

[Robert Kaiser]

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 12

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 13

[Karsten Düsterloh]

Expiring meta bugs is just pure non-sense.