This becomes more problematic the more email a user has to search. With a large account, this can result in very long search times, which users are more likely to understand if the email is old. If it is a recent email, users expect to see the search result more quickly.
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: thunderbird 7.0.1+build1+nobinonly-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
AddonCompatCheckDisabled: False
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: CONEXANT Analog [CONEXANT Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: james 1977 F.... pulseaudio
BuildID: 20110929183320
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'PCH'/'HDA Intel PCH at 0xd2520000 irq 44'
Mixer name : 'Intel CougarPoint HDMI'
Components : 'HDA:14f1506e,17aa21da,00100000 HDA:80862805,80860101,00100000'
Controls : 20
Simple ctrls : 8
Card29.Amixer.info:
Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw unknown'
Mixer name : 'ThinkPad EC (unknown)'
Components : ''
Controls : 1
Simple ctrls : 1
Card29.Amixer.values:
Simple mixer control 'Console',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Channel: release
Date: Wed Nov 2 20:02:56 2011
EcryptfsInUse: Yes
ForcedLayersAccel: False
IfupdownConfig:
auto lo
iface lo inet loopback
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
IpRoute:
default via 192.168.1.1 dev wlan0 proto static
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.102 metric 2
Prefs:
places.database.lastMaintenance - 1320169182
extensions.lastAppVersion - 7.0.1
network.cookie.prefsMigrated - true
gfx.blacklist.suggested-driver-version - Mesa 7.10.3
places.history.expiration.transient_current_max_pages - 121141
Profiles: Profile0 (Default) - LastVersion=7.0.1/20110929183320 (Running)
RunningIncompatibleAddons: False
SourcePackage: thunderbird
UpgradeStatus: Upgraded to oneiric on 2011-10-17 (17 days ago)
dmi.bios.date: 04/01/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 8DET42WW (1.12 )
dmi.board.asset.tag: Not Available
dmi.board.name: 4286CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr8DET42WW(1.12):bd04/01/2011:svnLENOVO:pn4286CTO:pvrThinkPadX220:rvnLENOVO:rn4286CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 4286CTO
dmi.product.version: ThinkPad X220
dmi.sys.vendor: LENOVO
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 FirePHP/0.2.1
Build Identifier: 2.0.0.17
I have migrated to Thunderbird from Outlook because Outlook's search feature was too slow. I have imported a database with 2 years worth of emails. Thunderbird's search is faster, but it starts with the *oldest* messages; that means that for full body searches (ex.: body contains: "new ftp password") I have to wait 5+ minutes to get to newer (more relevant) messages.
I know that I can limit the messages to, say, last 100 days or 400 days; however, I usually don't know how many days ago the relevant message was sent. Besides, that is an ugly and non-elegant solution.
Reproducible: Always
Steps to Reproduce:
1. Get a big email database
2. Start either a simple or advanced search using "body contains".
Actual Results:
The search takes a long time (which is OK given the data size), result list is updated on-the-fly (which is very good), but oldest results appear first (which is undesired).
Expected Results:
The results appear starting from most recent messages.
I am doing a local search, not an IMAP search.
I am marking this bug/feature request as "major", because it makes one of the most used functions (search) unusable in my case.