11.00 KB, application/octet-stream
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/20090929 SeaMonkey/2.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/20090929 SeaMonkey/2.0pre Download Manager, Search (sometimes) returns no results Reproducible: Always Steps to Reproduce: (exit SeaMonkey, replace existing downloads.sqlite with attached sample, restart SeaMonkey) 1. open download manager (with attached sample) 2. place focus on images3.jpeg 3. search for 3.jpeg (images3.jpeg should return) 4. close the search (X) (images3.jpeg should be semi-highlighted at the bottom of the window) 5. place focus on www.seamonkey-project.org 6. jump to Search, search for 'download' Actual Results: Results window is blank. Expected Results: Results window should not be blank. 3 different download.mozilla*.org entries should populate the window. Hard enough for me to describe/duplicate this bug. Whatever the problem is here, is likely going to be related to Bug 519612 - Download Manager, Search Results Blank Out. Further there is a likely data loss bug (I have seen entries disappear from Download Manager after Search) that again will be related (& even harder yet for me to quantify).
Created attachment 403703 [details] Sample downloads.sqlite from which I can duplicate bug Use this file to replace existing downloads.sqlite in test profile.
This looks to occur in the May 30 build too (which I believe to be 1 day after the new download manager landed) so appears there would be no regression range to look for. Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090530 SeaMonkey/2.0b1pre
This may only be occurring when the Download Manager window is NOT maximized. Further, when run maximized, you will see that results /are/ returned. But if you then "unmaximize" (Restore Down) the window, the results "vanish", which likely is Bug 519612, Download Manager, Search Results Blank Out. Windows XP SP3, MS Windows "Classic" theme. (Sometimes Windows Classic vs Windows XP themes can make a difference.)
Unrelated to the Windows theme.
Just an off the wall comment, may be totally unrelated, but ... "clientWidth, and the clientWidth returns 0, starting with Fx3" Look what al_9x says starting about here, http://forums.informaction.com/viewtopic.php?p=11883#p11883 Maybe something similar is happening here?
therube, do you still have this problem with the latest nightlies?
Issue reproducible on the branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20100504 SeaMonkey/2.0.5 Not an issue on the trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100511 SeaMonkey/2.1a1
Probably fixed by one of the improvments Neil Deakin did to the XUL backend on trunk. Since we can't find the regression range, and even so it is very unlikely to get backported to 1.9.1 I guess this can be marked as either WONTFIX for 2.0 branch or WORKSFORME for trunk.
Like Philip said in comment 8 that's very likely to stay unfixed in SeaMonkey 2.0.x, so let's resolve it as WFM for trunk.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.