44582 - Search UI: Needs Stop ability provided in UI (sometimes works, sometimes not)

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[laurel]

Using july 5 commercial build

We need a Stop mechanism for searches in progress.  
4.x changed the Search button to Stop when a search was in progress.
Or we could add a separate Stop button which would only enable when a search was
in progress.

Comment 1

[Alec Flett]

backend stop has been implemented right david? nominating for nsbeta2
if backend isn't implemented, I'll take off nsbeta2 nomination

Comment 2

[Alec Flett]

oops, actually add keyword

Comment 3

[David :Bienvenu]

yes, it's implemented but not tested.

Comment 4

[jglick]

The "Search" button should change to "Stop" if possible.

From the spec: 
Search - begins the search.  Only enabled when at least one row of criteria has 
been defined. Changes to "Stop" when a search is in progress so that a user can 
stop the current search if they want.

Comment 5

[Jay Patel [:jay]]

Putting on [NEED INFO] radar. Can you hit the close window button to stop the 
search?  Does the browser hang while searching or can you actually go other 
tasks during the search?

Comment 6

[laurel]

To answer jpatel:
Yes, you can hit the close button when a search is ongoing, but that's not
exactly the best idea (we have an open crasher bug when hitting reset during a
search).
Yes, you can switch to another window while search is in progress, but response
in that other window isn't necessarily great depending on what kind of search
you've got in progress (i.e. try a news search then try to do something else).

Still, I think this should be beta2.  If I have a search going and I realize I
specified something wrong, I would want to be able to smoothly interrupt it.  I
think this is basic functionality and we should get it into beta2. 

Comment 7

[laurel]

removed NEED INFO

Comment 8

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2.  Adding "nsbeta3" keyword 
for consideration of a fix for that milestone.

Comment 9

[selmer (gone)]

Adding mail4 triage nomination keyword.

Comment 10

[lchiang]

+ per mail triage

Comment 11

[robinf]

Adding myself to cc: list.

Comment 12

[lchiang]

P3 per mail triage

Comment 13

[lchiang]

second pass: - per mail triage

Comment 14

[scottputterman]

Sorry for the extra mail. Removing mail4 keyword.

Comment 15

[jglick]

Adding mail3 keyword so bug considered for 6.5

Comment 16

[scottputterman]

reassigning to gayatrib

Comment 17

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8

Comment 18

[gayatrib]

Attaching patch. And adding patch, review keywords.

Comment 19

[gayatrib]

Attachment: patch

Comment 20

[gayatrib]

Seth, David could you please do a review/super review for me? Thank you.

Comment 21

[David :Bienvenu]

r=bienvenu

Comment 22

[timeless]

-    onSearchHit: function(header, folder) 
+       onSearchHit: function(header, folder) 
     {
i think your indentation is wrong here.

Comment 23

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

gayatrib is going to provide a new patch that will stop the search on window
close, too.

Comment 24

[gayatrib]

new patch with search stop on window close.

Comment 25

[gayatrib]

Attachment: patch.

Comment 26

[gayatrib]

please review/super review. 

Comment 27

[David :Bienvenu]

sr=bienvenu

Comment 28

[racham]

r=racham

Comment 29

[gayatrib]

fix checked in.

Comment 30

[laurel]

Using feb8 commercial trunk build with Win98, linux rh6.0 and Mac OS 9.0

Well, I see that the Search button turns to Stop when a search is ongoing now,
but interrupting an ongoing search via the Stop button or Close button or close
box doesn't work. I tried (on all platforms several times) interrupting a simple
subject contains search on (IMAP) inbox containing 2000 messages and each time
the Stop/Close didn't work.  Stops the application cold, can't do anything else,
can't switch windows until the search completes.

Reopening... Stop doesn't work.

Comment 31

[laurel]

Hmmm... it seems to work sometimes (not all the time) on news searches, but I
still can't get a successful Stop or Close when doing IMAP searches. 

On some of the news searches I tried, Stop would sometimes not work, but Close
always seemed to.

Comment 32

[gayatrib]

I just tried this and it works. Both on pop and imap.

I think I know what the problem is when you say it works 'sometimes'.
Stop works only when the search is in progress. 

Many times, even after the search is done, the results are not displayed in the 
results thread pane immediately, as the UI gets populated slowly. Search 
completes in the backend much faster than results are loaded in the UI.

So if we click on stop anytime before the results display, it may not seem to 
work, as the search would actually be done, and the UI would be getting 
populated--in which case it would just ignore your click.

I am pretty sure this is what the problem is.
What you could try is probably do a real big search--on your entire mail account 
for a pretty common word in the subject line--like say "bug".

Results would be displaye din the results thread pane as each folder is 
searched.. then try stopping. This should make the stop work.

Stop working is obvious only on large searches... on small ones, the backend 
would be done, wont honor the stop, and it is the UI that is slow.

Marking it worksForMe. I tried it just now. Please reopen if problems still 
persist.

Comment 33

[laurel]

I DID try it on a large search, and Stop does not appear to work in my IMAP
tries. It may be that your explanation is true that the display to results pane
is underway, but to the user this stop would be useless then. 

What I'm seeing is that the delay is very long, so we may need to think about
Stop actually stopping the display to results pane activity, because if a user
is Stopping the search they do not care to wait while the display catches up --
they are doind a Stop to (quickly) move one.

I am reopening this.  I do not agree that the results I'm seeing are acceptable.

Comment 34

[gayatrib]

Ccing putterman for his thoughts. He knows this problem about the thread pane
being real slow and search results not being displayed for a while...

Comment 35

[scottputterman]

If this is because of the tree then it's probably the best we're going to get
until we stop using this tree. This will hopefully get cleared up as a side
effect of changing to an outliner.  My understanding is that the Search really
is interrupted, but you're right that there can be a long period of time where
you can't do anything. I'm removing the nsbeta1 whiteboard and keyword markings
and moving to future.  Hopefully this will just get taken care of.

Comment 36

[Matthew T (active 1999-2002)]

A simple fix would be to switch to a busy cursor while the tree is being 
populated.

Comment 37

[laurel]

FYI, this has not cleared up with the outliner.  There is still a drastic delay
when searching a large account on an account-wide basis.  To further complicate
the user perception, the barber pole stops, too, when the first batch of results
are displayed.  Even though it may still take awhile to really complete the
process of updating the pane, the user (me) can't tell if something's wrong
since the barber pole is stopped, status text is "searching" and the Stop button
cannot interrupt.  

Comment 38

[laurel]

Oh, and this is particularly horrible on Mac.

Comment 39

[laurel]

Just an update, circa may02: In a case where you're searching an account with
lots of folders and you've searched for something you know will not find a
match, Stop doesn't work very well. This kind of blows the theory that we've
stopped the search and are in the display results process,huh?

Comment 40

[David :Bienvenu]

it's quite possible that if you press stop "between" folders, we'll never notice
it because we don't get told that stop was pressed. I've found a way around this
for other situations which I can probably apply to search - basically,
remembering in the nsIMsgWindow that stop was pressed.

Comment 41

[laurel]

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

Comment 42

[Navin Gupta]

nominating 

Comment 43

[scottputterman]

moving to 0.9.2

Comment 44

[David :Bienvenu]

Attachment: proposed fix - check for stop between folders

Comment 45

[David :Bienvenu]

Navin and Seth, can I get an r= and sr= for this? Thanks! Basically, I just
check the window stopped flag between urls and time slices, and make sure I
clear the window stopped flag when starting a search.

Comment 46

[Navin Gupta]

r=naving

Comment 47

[Håkan Waara]

  PRBool done;
+ PRBool stopped = PR_FALSE;

Either set both of them to something, or neither. other then that r=hwaara.

Comment 48

[David :Bienvenu]

No, you're wrong, Hakan - look at the code a little more closely.  "stopped"
won't get set if m_window is null so it must be initialized.  "done" will always
be set by   searchSession->TimeSlice(&done);

Comment 49

[scottputterman]

moving to 0.9.3.  please hold onto this patch in case we can take it later.

Comment 50

[David :Bienvenu]

fix checked in to trunk - I don't think this is under consideration for the
branch so I'm marking it fixed.

Comment 51

[laurel]

Looks OK to me.
Tried searching large mail accounts, news accounts. All stop quickly. Tried
stopping at various times during the process. 
OK using aug10 commercial trunk build: win98, mac OS 9.0 and linux rh6.2