Closed Bug 594090 Opened 13 years ago Closed 13 years ago
Search Messages window/dialog bottom buttons not re-enabled after delete and repeated search
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20100701 SeaMonkey/2.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) 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.
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?
(In reply to comment #1) > Do you get any warnings/errors in the error console when this happens? No. Daniel
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Summary: search window bottom buttons not re-enabled after second search → Search Messages window/dialog bottom buttons not re-enabled after delete and repeated search
Whiteboard: [CLOSEME 2011-02-01 WFM]
Version: unspecified → Trunk
The db view isn't receiving its OnDeleteCompleted notification.
This is the advanced search version of bug 171711. Both bugs are regressions from bug 80897 because its patch only touched msgMail3PaneWindow.js.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #516233 - Flags: review?(mnyromyr)
(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!
Pushed changeset a5df7cbbe13f to comm-central.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Attachment #516233 - Flags: approval-seamonkey2.0.13?
Attachment #516233 - Flags: approval-seamonkey2.0.13? → approval-seamonkey2.0.13+
Pushed changeset bef7f141c308 to release/comm-1.9.1
You need to log in before you can comment on or make changes to this bug.