Closed
Bug 431273
Opened 17 years ago
Closed 16 years ago
Places should not try to load the entire history in the library
Categories
(Firefox :: Bookmarks & History, defect)
Firefox
Bookmarks & History
Tracking
()
VERIFIED
FIXED
Firefox 3.6a1
People
(Reporter: fittysix, Unassigned)
References
Details
(Keywords: perf, Whiteboard: [Fixed by bug 422163])
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042609 Minefield/3.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042609 Minefield/3.0pre I have about 21000 items in my history, and as you can imagine that takes firefox a good 5-10 seconds to load the history pane on my fairly fast computer with fairly fast disks, this just seems clunky. Reproducible: Always Steps to Reproduce: 1. Accumulate a year of history 2. History Menu > Show All History Actual Results: Firefox will appear to hang for a few seconds while it pre-populates the history. Expected Results: The history should only be lightly populated, and populate in real time while browsing the history. The download manager does this already, and it's much nicer. I don't see much use in pre-loading the entire thing, esp considering this problem will only grow as one accumulates more history.
Updated•17 years ago
|
Keywords: perf
Summary: Places should not try to pre-load the entire history → Places should not try to load the entire history when I open the sidebar
Comment 1•17 years ago
|
||
This is probably a duplicate of Bug 417262.
Reporter | ||
Comment 2•17 years ago
|
||
This bug isn't about the side bar, this is is in the Library window when you: 1. Click history menu 2. Click show all history I can certainly see it being related though, since history sidebar > view > By last visited is the same result as the default history view in places.
Summary: Places should not try to load the entire history when I open the sidebar → Places should not try to load the entire history in the library
Updated•17 years ago
|
Version: unspecified → Trunk
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•16 years ago
|
||
Is this a duplicate of bug 405254?
27763 items in history collected over 4 months. The "places.sqlite" file is at 16,896KB according to Windows XP. CPU performance spikes for a few seconds slowing usability of Firefox.
Updated•16 years ago
|
OS: Windows Vista → All
Hardware: x86 → All
Comment 6•16 years ago
|
||
I'm not seeing this issue in Build 20090413044519 of Firefox 3.5b4pre.
Comment 7•16 years ago
|
||
behavior changed with bug 422163.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [Fixed by bug 422163]
Target Milestone: --- → Firefox 3.6a1
Comment 8•16 years ago
|
||
verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b4pre) Gecko/20090414 Shiretoko/3.5b4pre
Status: RESOLVED → VERIFIED
Comment 9•15 years ago
|
||
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in
before you can comment on or make changes to this bug.
Description
•