Quick Search: Reloads message when coming out of quick search

NEW
Unassigned

Status

--
minor
17 years ago
3 years ago

People

(Reporter: scottputterman, Unassigned)

Tracking

(Blocks: 2 bugs)

Trunk
x86
Windows NT
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
Here's a behavior in quick search that would be cool if we could optimize.

1.  Type something that will have at least one result in Quick Search
2.  Select a message
3.  Clear Quick Search.
4.  We correctly reload the folder and select the message.  

It looks like the message gets reloaded.  Since it's already displaying, is
there a way to not reload it?

Comment 1

17 years ago
So you do not want message-pane to be cleared, when coming out of quick search?
(Reporter)

Comment 2

17 years ago
I'm just saying that if the message is already loaded and we are about to select
it again, we shouldn't reload it.  Or is there a reason why it needs to reload it?
(Reporter)

Updated

17 years ago
Blocks: 103734

Comment 3

17 years ago
The reason it has to be reloaded is because we clear the message-pane and
thread-pane selection when coming out of quick search, so the same message 
has to be again loaded. 
(Reporter)

Updated

17 years ago
Blocks: 106943
(Reporter)

Updated

17 years ago
No longer blocks: 103734

Comment 4

17 years ago
After some investigation, I have found reloading is the safe thing to do
because we cannot rely whether message was fully loaded as we go from 
one view to another. I see myself ending up with half loaded messages if
I just try to hidMessageHeaderPane() and then showMessageHeaderPane when 
needed. 

seth what do you think, cc mscott for his opinion too. 

Updated

17 years ago
Blocks: 157217
mass re-assign.
Assignee: naving → sspitzer
Product: Browser → Seamonkey

Updated

14 years ago
Assignee: sspitzer → mail

Comment 6

13 years ago
I've come across a related problem: when closing a quick search, the current message is not displayed, even when you select it in the top pane. I guess this is an optimisation to prevent the current message from being rendered unnecessarily, but in this case it's necessary to render the message.

To reproduce this bug: select a message in the top pane, start a quick search, close it without selecting anything (no message displayed) and then select the current message in the top pane (still no message displayed).

Cheers,
Michael

Comment 7

13 years ago
WFIW, Thunderbird *appears* to not do this (don't see a downloading or loading message in status line as in Seamonkey).  So it is possible to make it not reload. 


(In reply to  Michael comment #6)
> To reproduce this bug: select a message in the top pane, start a quick search,
> close it without selecting anything (no message displayed) and then select the
> current message in the top pane (still no message displayed).

This WFM (doesn't fail as described) with trunk Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060101 SeaMonkey/1.5a

Michale can you test with a trunk build to see that it fails with multiple examples?



Comment 8

13 years ago
I can confirm that this bug is fixed in Thunderbird 1.5 (20051201) for Windows - can't test Seamonkey here I'm afraid, but it was Thunderbird that originally displayed the bug.

Thanks,
Michael

Comment 9

13 years ago
Sander and I confirm still broken in Seamonkey, even though it is doesn't happen in Thunderbird.
QA Contact: laurel → search

Updated

13 years ago
Severity: normal → minor
Wayne (or someone), does it still happen after 2 years?

Comment 11

11 years ago
yes, still on TB trunk.

check out another bug that talks about read status getting change to unread coming out of quick search. has a good testcase.

Updated

10 years ago
Component: MailNews: Search → MailNews: Message Display
Assignee: mail → nobody
QA Contact: search → message-display
You need to log in before you can comment on or make changes to this bug.