594090 - Search Messages window/dialog bottom buttons not re-enabled after delete and repeated search

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: General, defect)

Description

[Daniel B.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6

In the mail Search window, if you perform a second search, sometimes the
buttons at the bottom of the window are not re-enabled when you click
on some message lines.

Reproducible: Sometimes

Steps to Reproduce:
1. In MailNews, invoke Search Messages.
2. Do a search.
3. Click on the Search button to perform a search.
4. Notice that the buttons at the bottom become disabled.
5. Click on a message in the results lists.

Actual Results:  
6. The buttons at the bottom remain disabled, even when the search has
completed and even there is a selection in the results list table.

Expected Results:  
6. The button should become re-enabled when cause there to be a selection
in the list.

When the problem happens, it "sticks" until the Search window is closed
and re-opened.

Comment 1

[Bruno 'Aqualon' Escherl]

Don't see this with a SeaMonkey/2.0.8pre nightly and latest trunk (Linux).

Do you get any warnings/errors in the error console when this happens?

Comment 2

[Daniel B.]

(In reply to comment #1)

> Do you get any warnings/errors in the error console when this happens?

No.  

Daniel

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

Confirming with trunk and the below STR (adjusting summary):

1. Open the Advanced Search dialog
2. Do a search which results in at least two found entries
3. Select one or more search results, but not all
4. Press Delete (either the key or the button)
5. Repeat the search
6. Select one or more of the results

Expected: Buttons are enabled
Actually: Buttons are disabled (workaround: close and reopen dialog)

You'll also notice that the search results don't properly update when you press Delete (only entries you hover with the mouse are updated, otherwise if you don't move the mouse it looks like the delete didn't succeed if you don't look at the status bar which updates correctly).

It seems like the internal state of the view/listeners is totally broken. With a debugger like Venkman you'll see that before the delete action, nsSearchResultsController.isCommandEnabled (SearchDialog.js) is called when you hit Search or select a search result. After the delete action it's only called when you hit Search, i.e. the buttons probably keep being disabled because the nsSearchResultsController somehow got disconnected from the search results view.

Unfortunately comparing with TB's code doesn't help because it uses their JS folder pane code which we don't have yet. :-(

Karsten, Neil, any idea?

Comment 4

[[e-mail]]

The db view isn't receiving its OnDeleteCompleted notification.

Comment 5

[[e-mail]]

Attachment: Proposed patch

This is the advanced search version of bug 171711. Both bugs are regressions from bug 80897 because its patch only touched msgMail3PaneWindow.js.

Comment 6

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #5)
> Created attachment 516233 [details] [diff] [review]
> Proposed patch

Works beautifully, thanks a ton! I think we should even take this for 2.0.next.

> This is the advanced search version of bug 171711. Both bugs are regressions
> from bug 80897 because its patch only touched msgMail3PaneWindow.js.

Wow, that's old!

Comment 8

[[e-mail]]

Pushed changeset a5df7cbbe13f to comm-central.

Comment 9

[[e-mail]]

Pushed changeset bef7f141c308 to release/comm-1.9.1