If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

QuickSearch: Clear a no-match search, select msg doesn't load body

VERIFIED FIXED in mozilla1.0

Status

SeaMonkey
MailNews: Message Display
P2
major
VERIFIED FIXED
16 years ago
13 years ago

People

(Reporter: laurel, Assigned: Navin Gupta)

Tracking

({regression})

Trunk
mozilla1.0
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

2.44 KB, patch
(not reading, please use seth@sspitzer.org instead)
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

16 years ago
Using feb01 commercial trunk build

After you clear a search which found no matches, when you select a message in
the thread pane the body won't load.  Once you focus the folder pane or select
another folder and return, selectin messages will now load content.

1.  Open a mail folder or newsgroup, search bar is shown.
2.  Type something in the search bar which will not match any subject or sender
in the folder view.
3.  Empty search view appears, click Clear.
4.  Back in folder view, select any message.

Result:  Message body doesn't load.  Must focus folder pane or select another
folder and return, then selecting message will load properly.

Note:  This problem doesn't happen if you've done a search which matches items
in the view.
(Reporter)

Updated

16 years ago
QA Contact: esther → laurel
(Reporter)

Comment 1

16 years ago
Was OK with yesterday's build, regressed in today's build.
Keywords: nsbeta1, regression
(Reporter)

Comment 2

16 years ago
*** Bug 123718 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

16 years ago
Severity: normal → major
(Reporter)

Comment 3

16 years ago
*** Bug 124934 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Status: NEW → ASSIGNED
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 4

16 years ago
Created attachment 69707 [details] [diff] [review]
proposed fix

The fix is to make sure that whenever we are calling Save..Selection() we call
restoreSelection() because we suppress selection events in Save..Selection()
and
unsupress them in restoreSelection(). And to make this work
m_saveAndRestoreSelectionCount should be in sync. Here since we don't have any
hdrs in the  view we don't need to do all this SaveSelection and
RestoreSelection(). I have checked other instances of SaveSelection() and made
sure that we don't return early without RestoreSelection().

This bug was caused indirectly by seth's fix to bug 116174.
(Assignee)

Comment 5

16 years ago
I mean if you don't call restoreSelection() m_saveAndRestoreCount will no
longer be in sync. 
Comment on attachment 69707 [details] [diff] [review]
proposed fix

sr=sspitzer

thanks for fixing my mistake.
Attachment #69707 - Flags: superreview+
(Assignee)

Comment 7

16 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 8

16 years ago
OK using feb18 commercial trunk build: win98, mac OS 10.1, linux rh6.2
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.