Last Comment Bug 595530 - Searching bookmarks and history is much slower after SQLite 3.7.x upgrade
: Searching bookmarks and history is much slower after SQLite 3.7.x upgrade
Status: VERIFIED FIXED
[Tsnap][fixed-in-places][SQLlite3.7.4...
: perf, regression
Product: Firefox
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: unspecified
: All All
: -- critical with 16 votes (vote)
: Firefox 4.0b9
Assigned To: Marco Bonardo [::mak]
:
Mentors:
: 595851 596208 601095 606707 618216 621935 639543 (view as bug list)
Depends on: 458026 599641 606053
Blocks: 490512 560198 SQLite3.7.1
  Show dependency treegraph
 
Reported: 2010-09-11 11:59 PDT by wamsaya
Modified: 2014-08-02 11:46 PDT (History)
35 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
betaN+


Attachments
remove LENGTH check (850 bytes, patch)
2010-10-13 03:12 PDT, Marco Bonardo [::mak]
sdwilsh: review+
Details | Diff | Review

Description wamsaya 2010-09-11 11:59:57 PDT
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre

With latest hourly, when I open the bookmarks and history library and search through items, the search is so slow and minefield frequently freezes as long as I keep this window open.

Reproducible: Always

Steps to Reproduce:
1.open bookmarks and history library
2.Do a search within items there

Actual Results:  
Search among items very slow, navigator freezes.

Expected Results:  
Fast search results among bookmarked and history items, minefield still responsive.
Comment 1 Bryan Reynolds 2010-09-25 02:50:47 PDT
Confirmed here. It has been going on for quite a few weeks. I came to bugzilla trying to find the bug for it. Sure hope it is addressed before final.
Comment 2 Bryan Reynolds 2010-09-30 19:44:37 PDT
Some discussion:
http://forums.mozillazine.org/viewtopic.php?p=9964421#p9964421
(as well as the 2 posts directly above it)
Comment 3 Marco Bonardo [::mak] 2010-10-01 01:50:25 PDT
is searching bookmarks or searching history that is slow? I've tried here, searching bookmarks is instant, searching history takes a couple seconds, but history is quite large
Comment 4 Bryan Reynolds 2010-10-01 02:34:31 PDT
for me, it is both. but history is considerably slower. I have about 40 days of history right now
Comment 5 ronin.achilles 2010-10-01 21:10:37 PDT
Confirmed. Has been happening for quite sometime... Firefox kind of hangs for sometime whenever I search for bookmarks from within Library or Sidebar...I really thought this was a regression and will be fixed ultimately... but am not sure if its being worked upon.
Comment 6 Marco Bonardo [::mak] 2010-10-02 01:04:05 PDT
*** Bug 601095 has been marked as a duplicate of this bug. ***
Comment 7 Marco Bonardo [::mak] 2010-10-02 01:06:39 PDT
So, people that can reproduce the problem could help me finding a regression range. I need you to try out the builds in ftp://ftp.mozilla.org/pub/firefox/nightly/ till you find out the first one that is slow.

That would greatly help.
Comment 8 Bryan Reynolds 2010-10-02 03:13:13 PDT
Thanks for your confirmation Marco. I am working on that now. Hopefully I can find a window sometime tonight for you.
Comment 9 Bryan Reynolds 2010-10-03 01:43:08 PDT
Sorry for the delay. I spent about 20 mins testing builds tonight, here is what I came up with:

ftp://ftp.mozilla.org/pub/firefox/nightly/2010/07/2010-07-21-04-mozilla-central/firefox-4.0b3pre.en-US.win32.zip

the above build does NOT experience the issue

ftp://ftp.mozilla.org/pub/firefox/nightly/2010/07/2010-07-24-04-mozilla-central/firefox-4.0b3pre.en-US.win32.zip

the above build DOES experience the issue.

In my testing, I got to test a few builds both before and after the above builds to confirm that the issue is still in place after 7/24, but not before 7/21. I hope this is of some help.
Comment 10 Bryan Reynolds 2010-10-03 01:53:44 PDT
Ack, i should have narrowed it further.

the issue is not in place in this build:
ftp://ftp.mozilla.org/pub/firefox/nightly/2010/07/2010-07-23-04-mozilla-central/firefox-4.0b3pre.en-US.win32.zip

so it looks like it happened sometime between 7/23 and 7/24 nightlies.
Comment 11 Marco Bonardo [::mak] 2010-10-03 02:38:55 PDT
that should point to:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58101a16aff7&tochange=30239e4cebd8

one interesting change is the upgrade to sqlite 3.7.0
Comment 12 Marco Bonardo [::mak] 2010-10-04 03:08:07 PDT
So in the range effectively there is nothing related to searches but sqlite upgrade.
sqlite 3.7.0 had a known perf regression due to automatic indexing, it was backed out and replaced with sqlite 3.7.1 that has that fixed.
Looks like in some case there is still some perf regression? Unfortunately I cannot reproduce on my database, so there must be specific entries in the database that cause it.
I really need a json backup of your bookmarks that once imported in a new profile can cause this bug, otherwise I'll never be able to reproduce. Please send it to me by mail.

in the meanwhile you could try executing this code in the Error Console and tell me if immediately later the search is faster:
Components.utils.import("resource://gre/modules/PlacesUtils.jsm");PlacesUtils.history.QueryInterface(Components.interfaces.nsPIPlacesDatabase).DBConnection.executeSimpleSQL("pragma automatic_index = false");
Comment 13 Bryan Reynolds 2010-10-04 04:55:22 PDT
Well... that is unfortunate, but for privacy reasons I can't do that. Hopefully someone here will. I should note that at one point I re-installed firefox fresh and fetched all of my bookmarks from Sync, would the database still have these errors if I restored them this way? What about if i restored them from an exported .html file?

I got an error inputting that bit of code into the error console. (for some stupid reason firefox does not let me copy/paste from the error console but..."
Error: uncaught exception
Comment 14 3e2224c2 2010-10-04 05:55:42 PDT
(In reply to comment #13)
> Well... that is unfortunate, but for privacy reasons I can't do that. Hopefully
> someone here will. 

I was expecting the same :)

>I should note that at one point I re-installed firefox fresh
> and fetched all of my bookmarks from Sync, would the database still have these
> errors if I restored them this way? What about if i restored them from an
> exported .html file?

I tried that. The problem persists after importing json, html or synching.
Comment 15 Marco Bonardo [::mak] 2010-10-04 07:05:23 PDT
ok, got a json by mail, and looks like I can reproduce. Taking the bug for now.

Also, asking blocking because the performance difference is pretty much noticeable, searching bookmarks/history in such condition is a pain.
Comment 16 Marco Bonardo [::mak] 2010-10-04 08:32:28 PDT
tested the query with the database with sqlite commandline, both 3.6 and 3.7, no differences (it takes just a few ms). But the same query in our code hangs for 30 seconds, most of the time is spent in ResultsAsList (but we already knew that), the crazy stuff is that executeStep seems to wait for a mutex on each step.
Comment 17 Marco Bonardo [::mak] 2010-10-04 08:58:23 PDT
hrm, I did a wrong measure. Now I can reproduce in SQLite command line too. This is a regression in SQLite performances.
Using the included .timer option in the command line, sqlite 3.6.22 executes the query in 0.07s while 3.7 takes 12.7s
Comment 18 Shawn Wilsher :sdwilsh 2010-10-04 09:01:14 PDT
We need a copy of the query and a sample db the SQLite folks can take a look at it.

Seeing as how we landed 3.7.1 on 1.9.2, 3.6 is going to get hit with this too it looks like.
Comment 19 Marco Bonardo [::mak] 2010-10-04 09:36:19 PDT
I've sent our schema and the query to SQLite support, I've not sent any private information nor the database to them.
I'll try to generate a new database without no private data in it for them, just dummy data, in case the schema would not be enough.
Comment 20 Shawn Wilsher :sdwilsh 2010-10-04 09:42:49 PDT
(In reply to comment #19)
> I've sent our schema and the query to SQLite support, I've not sent any private
> information nor the database to them.
> I'll try to generate a new database without no private data in it for them,
> just dummy data, in case the schema would not be enough.
Probably won't need it actually, so don't worry about it unless they ask for it.
Comment 21 Shawn Wilsher :sdwilsh 2010-10-04 15:56:52 PDT
This will either be fixed by bug 598306 or by bug 599641.  Drivers should set blocking flags as they see fit.
Comment 22 Marco Bonardo [::mak] 2010-10-04 16:19:12 PDT
Actually I think the right solution is to make the query non dependent on sqlite optimizer choices. See the mail I just sent.
Thus, we should drop the  LENGTH check and fix bug 458026.
ANALYZE is nice to have, but I don't want queries to depend too deeply over it (if data gets misaligned for any reason, the query becomes slow again), and we could not be able to get analyze on 3.6.x early.

On the other side bug 458026 hits just a small percentage of users, thus we can stop work-arounding the issue in the query and fixing the data and the bug that allows to set bogus data.
Comment 23 Marco Bonardo [::mak] 2010-10-04 18:19:48 PDT
Current SQLite 3.7.3 trunk has a patch for this issue (confirmed working). Since we can't yet tell if that patch will be in final (could be backed out due to regressions even if drh is positive about it sticking) I'd say to proceed also with our plan to try to fix bug 599641 and bug 458026.
Comment 24 Marco Bonardo [::mak] 2010-10-05 07:10:45 PDT
*** Bug 596208 has been marked as a duplicate of this bug. ***
Comment 25 Marco Bonardo [::mak] 2010-10-13 03:12:26 PDT
Created attachment 482807 [details] [diff] [review]
remove LENGTH check

bug 458026 has a patch (waiting for review) and 3.7.3 is out (just needs to be updated on both branches).
This is a patch to remove LENGTH check. The check itself is just workarounding bug 458026, but it's a bug that hits in really rare cases (the user has to edit name of a tag container and set it empty), so it's not really useful, probably just slowing down things.
I'm putthig this here apart from bug 458026 because it is a query change and I think we should push it on Places branch to avoid too complicated merges.
Comment 26 Shawn Wilsher :sdwilsh 2010-10-13 13:42:30 PDT
Comment on attachment 482807 [details] [diff] [review]
remove LENGTH check

r=sdwilsh.  I suspect we may want to take some patch for branch here too.
Comment 27 Marco Bonardo [::mak] 2010-10-18 07:39:39 PDT
(In reply to comment #26)
> r=sdwilsh.  I suspect we may want to take some patch for branch here too.

Agree, or SQLite 3.7.3. The problem with this patch is that I think we can't get it on 1.9.2 branch before it is on central
Comment 28 Marco Bonardo [::mak] 2010-10-20 02:07:33 PDT
*** Bug 595851 has been marked as a duplicate of this bug. ***
Comment 29 Marco Bonardo [::mak] 2010-10-20 18:06:37 PDT
http://hg.mozilla.org/projects/places/rev/5c484855cda4
Comment 30 Marco Bonardo [::mak] 2010-10-21 08:45:40 PDT
ugh there is another entry in mDBGetTags, I'll remove it as well.
Comment 31 Marco Bonardo [::mak] 2010-10-22 08:15:38 PDT
(In reply to comment #30)
> ugh there is another entry in mDBGetTags, I'll remove it as well.

and also Autocomplete has a LENGTH check (patching in bug 606460, but worth annotating these changes here)
Comment 32 Marco Bonardo [::mak] 2010-10-25 02:57:03 PDT
*** Bug 606707 has been marked as a duplicate of this bug. ***
Comment 33 Marco Bonardo [::mak] 2010-11-02 12:33:23 PDT
This should probably be blocking final rather than beta8, but I'd be pretty much happy if SQLite 3.7.3 could make b8 (Bug 598306 is marked as final+ so far).
Most of the work is on Places branch fwiw.
Comment 34 Shawn Wilsher :sdwilsh 2010-11-02 13:04:19 PDT
(In reply to comment #33)
> This should probably be blocking final rather than beta8, but I'd be pretty
> much happy if SQLite 3.7.3 could make b8 (Bug 598306 is marked as final+ so
> far).
> Most of the work is on Places branch fwiw.
We can probably just land this on mozilla-central.  It's baked for quite a while on places.
Comment 35 Dietrich Ayala (:dietrich) 2010-11-17 06:29:23 PST
This does not need to block beta8. We'd like bake-time since it requires the SQLite upgrade, so moving this to betaN, with the plan being to land it after the branching happens.
Comment 36 Bubba 2010-11-21 09:42:40 PST
PLEASEEE release this fix ASAP!
Comment 37 Marco Bonardo [::mak] 2010-12-10 02:36:15 PST
*** Bug 618216 has been marked as a duplicate of this bug. ***
Comment 38 Ken Brucker 2010-12-10 09:23:45 PST
I suspect this is the issue I'm having related to searches for tags that pegs FF CPU usage at a sustained 100% for about 30 seconds.  I make heavy use of tags and this regression makes the 3.6.11 and later releases of FF unusable for me.  Other searches for me are fine.  It's only tag related searches that show a problem in my experience.

Another performance observation - My saved searches based on tags take a long time.  Typing a tag into the location bar is slower than 3.6.10 but does not peg the CPU or take nearly as much time as a saved search or doing a search from the organize bookmarks window.
Comment 39 msth67 2010-12-14 02:13:58 PST
I think this may possibly affect the functionality of the "Context Search" addon as well:at the same time the issue about slow bookmarks searching surfaced,I've also observed that the list of search engines to which this addon points now takes a lot longer to pop up.
Comment 40 Greg 2010-12-15 15:52:30 PST
I have this problem as well, it's been in all of the firefox betas, and currently I'm running the latest nightly. Searching history seems to have gotten worse, as now Minefield freezes completely.

I haven't tried searching bookmarks, but last I tried it took over 30 seconds. Right now I don't want to try it because I'm typing this, and if it freezes... well, I'll have to retype it. :-p

Just a note, I also make heavy use of tags. I love tags, and I love bookmarks. I hope Firefox 4 has this fixed in the final release, because right now my carefully curated bookmarks are unusable, and so is the history.
Comment 41 Bubba 2010-12-15 16:44:11 PST
This is a HUGE PROBLEM - it is a BIG useability issue for the browser in my opinion.

Please fix this ASAP, or it could be the straw that pushed me to ..rome !
Comment 42 Marco Bonardo [::mak] 2010-12-15 16:48:33 PST
patience please, it will be fixed pretty soon.
Comment 43 Heribert Slama 2010-12-15 18:09:04 PST
(In reply to comment #42)
> patience please, it will be fixed pretty soon.

Since most people here talk about Firefox 4, I want to remind you that Firefox 3.6.13+ also needs fixing.
Comment 44 Marco Bonardo [::mak] 2010-12-16 14:52:20 PST
Fixed by query changes and SQLite upgrade on central.
We need the SQlite upgrade on 1.9.2, that will be tracked in the sqlite bug.
Comment 45 jeff 2011-01-02 15:19:46 PST
I have the same bookmarks search problem in firefox 3.12 basically won't search at all. Tried disabling all extensions etc. Any updates on a fix for this I see resolved/fixed below? 4.08 or 4.09beta?  Hate to lose ability to search tags.
Yes gravitating toward Chrome lately. Firefox has turned into crashfox/firecrash with many windows open and memory leaks this bug definitely doesn't help. Hope a solution appears thanks all above at least I know I'm not alone with this
Comment 46 Marco Bonardo [::mak] 2011-01-03 07:23:48 PST
*** Bug 621935 has been marked as a duplicate of this bug. ***
Comment 47 franc 2011-01-05 10:56:58 PST
I have this bug in Firefox 3.6.13 and 4.0 Beta 8 on Mac OSX 10.6.5 since some months already.
I hoped it is fixed with newer updates or with 4 beta, but nothing has changed.
It takes some seconds too much if i search in the bookmarks and many seconds if i edit bookmarks and switch to another field.
Is there any hope for a fix?
Comment 48 Shawn Wilsher :sdwilsh 2011-01-05 18:15:48 PST
(In reply to comment #47)
> I have this bug in Firefox 3.6.13 and 4.0 Beta 8 on Mac OSX 10.6.5 since some
> months already.
It is fixed in Firefox 4 beta 9 (not yet released).
Comment 49 franc 2011-01-06 04:25:51 PST
It is working in Firefox 3.6.10, so i downloaded it from:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.6.10/mac/

and then just switched off the updates. Amazing that there are not much more mac users are complaining, the library is really slow with this bug.
Comment 50 Ralf 2011-01-06 19:04:17 PST
For users running Linux there I have a (relative) simple solution:

1. Download the actual sqlite sources
 wget http://www.sqlite.org/sqlite-autoconf-3070400.tar.gz

2. Uncompress, configure and compile the sources
 tar xf sqlite-autoconf-3070400.tar.gz
 cd sqlite-autoconf-3070400
 ./configure
 make

3. Replace the broken library shipped with Firefox with the freshly compiled one

You have to figure out where the libsqlite3.so of your Firefox installation resides. Simply type "locate sqlite3.so | grep firefox" to find it. On Ubuntu 10.04 aka Lucid Lynx it is: /usr/lib/firefox-3.6.13/libsqlite3.so

 sudo cp .libs/libsqlite3.so.0.8.6 /usr/lib/firefox-3.6.13/libsqlite3.so

4. Restart Firefox

5. Be happy (the history and bookmark search should be as fast as in 3.6.10)

It is a really BAD idea to downgrade to an older version of Firefox since there was a bunch of critical security bugs fixed in the last releases.
Comment 51 Ken Brucker 2011-01-07 07:13:05 PST
Similar trick for OSX would be great.  When I try I get an error that the version of the libsql library is too old and FF refuses to start.

Will this issue also be fixed in 3.6.14?  For those of us it hits, it's a really serious usability regression.
Comment 52 franc 2011-01-07 08:33:40 PST
Just use 3.6.10, it works.
But it is not possible to just use the dylib of 10, it wont work in 13.
Comment 53 Bubba 2011-01-07 14:31:27 PST
Yes, this is a HUGE usability issue! If you're used to using tags it's almost unbearable.
Comment 54 franc 2011-01-07 15:34:43 PST
This is very very right. I suffered so much i nearly thougt to switch to chrome for mac.
Comment 55 jeff 2011-01-13 00:02:15 PST
Have there been any updates on this bug and a fix? apple platform 10.5 or above will 4.09 beta cure this  as as eluded to above? I will attempt back pedal to Firefox  3.6.10 at some point soon as last ditch Tiddlywinks with fire fox??? apparently that works? ... I've been working with Google Chrome now as my main browser... soon to switch away to Chrome permanently. This crashfox is just getting so messy. To buggy to unreliable. Tagged bookmarks was at some point a core firefox organizational concept. confused very confused.... at the de-evolution into the future of firefox
Comment 56 Greg 2011-01-13 08:36:21 PST
Guys, please read the thread, and for that matter, read the bug report header itself. You'll see that this bug has been fixed, and how you can get it.

Every time one of you fails to do this, about 33 people get an email in their inbox. I am one of those people. We get to hear your unnecessary complaints. Well, I've had enough. I'm removing myself from this bug's CC list.

Thanks to the Mozilla developer(s) for fixing this issue. With the exception of the Flash player being comparatively slower in FF than other browsers, the latest FF nightlys are great, I'm looking forward to the February release.
Comment 57 Bubba 2011-01-13 15:24:15 PST
@Greg: "... read the bug report header itself. You'll see that this bug has been fixed, and how you can get it."

Oh, really. Well, after reading the report header I'm none the wiser as to "how you can get it (the fix)".

Maybe you can enlighten me?
Comment 58 Shawn Wilsher :sdwilsh 2011-01-13 15:26:24 PST
(In reply to comment #57)
> Maybe you can enlighten me?
Resolved as FIXED in comment 44, and the Target Milestone (when users will see it fixed) was set to Firefox 4.0 beta 9.
Comment 59 franc 2011-01-13 15:34:09 PST
Humbug.
It is maybe fixed in 4.09b but not in 3.6.13+
I won't use the 4 beta as it is beta and then it breaks some of my important Add-Ons.
So this big-bug is still not fixed.
And i don't know what happened, but even with disabled Firefox-Updates, somehow i had again the buggy FF 3.6.13 and I had to switch manually back to 3.6.10 again.
Comment 60 Michał Gołębiowski [:m_gol] 2011-01-13 16:16:26 PST
(In reply to comment #59)
> It is maybe fixed in 4.09b but not in 3.6.13+
FIXED status means only that the bug is fixed in trunk, which is currently 4.0b10pre. For all other versions branches are needed, e.g. blocking1.9.2: 14+ (I suggest setting that BTW).
Comment 61 Shawn Wilsher :sdwilsh 2011-01-13 16:19:06 PST
(In reply to comment #60)
> FIXED status means only that the bug is fixed in trunk, which is currently
> 4.0b10pre. For all other versions branches are needed, e.g. blocking1.9.2: 14+
> (I suggest setting that BTW).
It is requested in bug 598306, which is the same bug that fixed this bug on trunk.
Comment 62 jeff 2011-01-16 20:21:39 PST
Hey Greg,

Sorry to be a pain but I really don't see from this thread the sure fire fix for this bug.  If you are still on here and haven't run in horror from the rest of us I assume you mean updating to 4.09B. that is the fix you say is fact, the sure fire on the ground fix.  I will try this  next few days and report back although now of course it seems Micheal above is saying fix is actually in 4.0b10pre so is this a movable feast...a kick the can forward story because no one is really sure. This thread started in what September of last year? "Not good for what is in my opinion such a core element of the firefox browser  This problem should not still be bouncing around here. It renders bookmarking virtually useless for most of us.    You seemed quite sure so maybe for the rest of us not so savvy Firefoxers you can just re confirm that in fact 4.09 update will in fact fix this problem. i don't know what this means nor how to do this: 
FIXED status means only that the bug is fixed in trunk, which is currently4.0b10pre. For all other versions branches are needed, e.g. blocking1.9.2: 14+
(I suggest setting that BTW)

above  seems like a ridiculous waste of effort for the average firefox user in  attempt to find a cure. "chrome works" I think?

Thanks! I don't mind being a crash test dummy for this within reason. And I certainly don't want to bother the people working so hard to fix this and the many other problems Firefox is having right now. But you really do have to wonder why this problem is not an absolutely core priority for the firefox team to make go away. Without this feature i feel like I'm using a version of firefox from the browser dark ages and be sure there is a lot of shock and complaining out there that doesn't make this message board. February is 2 weeks away when is the official release of this browser??
Comment 63 maxburley 2011-01-27 14:57:13 PST
(In reply to comment #50)
> For users running Linux there I have a (relative) simple solution:
> 
> 1. Download the actual sqlite sources
>  wget http://www.sqlite.org/sqlite-autoconf-3070400.tar.gz
> 
> 2. Uncompress, configure and compile the sources
>  tar xf sqlite-autoconf-3070400.tar.gz
>  cd sqlite-autoconf-3070400
>  ./configure
>  make
> 
> 3. Replace the broken library shipped with Firefox with the freshly compiled
> one
> 
> You have to figure out where the libsqlite3.so of your Firefox installation
> resides. Simply type "locate sqlite3.so | grep firefox" to find it. On Ubuntu
> 10.04 aka Lucid Lynx it is: /usr/lib/firefox-3.6.13/libsqlite3.so
> 
>  sudo cp .libs/libsqlite3.so.0.8.6 /usr/lib/firefox-3.6.13/libsqlite3.so
> 
> 4. Restart Firefox
> 
> 5. Be happy (the history and bookmark search should be as fast as in 3.6.10)
> 
> It is a really BAD idea to downgrade to an older version of Firefox since there
> was a bunch of critical security bugs fixed in the last releases.

Thanks, Ralf. This had been "bugging" me for months before I stopped cursing and started searching for a solution.

I can confirm that your hack works and that your commands are correct for Ubuntu 10.04.
Comment 64 B Laz 2011-01-27 22:12:41 PST
I registered just to thank you!
(In reply to comment #50)
> For users running Linux there I have a (relative) simple solution:
> 
> 1. Download the actual sqlite sources
>  wget http://www.sqlite.org/sqlite-autoconf-3070400.tar.gz
> 
> 2. Uncompress, configure and compile the sources
>  tar xf sqlite-autoconf-3070400.tar.gz
>  cd sqlite-autoconf-3070400
>  ./configure
>  make
> 
> 3. Replace the broken library shipped with Firefox with the freshly compiled
> one
> 
> You have to figure out where the libsqlite3.so of your Firefox installation
> resides. Simply type "locate sqlite3.so | grep firefox" to find it. On Ubuntu
> 10.04 aka Lucid Lynx it is: /usr/lib/firefox-3.6.13/libsqlite3.so
> 
>  sudo cp .libs/libsqlite3.so.0.8.6 /usr/lib/firefox-3.6.13/libsqlite3.so
> 
> 4. Restart Firefox
> 
> 5. Be happy (the history and bookmark search should be as fast as in 3.6.10)
> 
> It is a really BAD idea to downgrade to an older version of Firefox since there
> was a bunch of critical security bugs fixed in the last releases.

Well thanks this works on Windows too.

1. download http://www.sqlite.org/sqlite-dll-win32-x86-3070400.zip
2. unzip to the Mozilla application folder (probably @ "%programfiles%\Mozilla Firefox" for cut & pasters, or wherever you've installed Firefox...)
3. you really just need to unzip sqlite3.dll --sqlite3.def does seem to have a purpose/need.

Works fine as of 3.6.13, a bit smaller library file than the new dll found in 4.0b10.  

Not sure how this was fixed, but found link to the bug from http://kb.mozillazine.org/Firefox_hangs#Hang_searching_bookmarks_and_history and I if people aren't using the beta, or branching, they feel encouraged to buy a new PC...
Comment 65 franc 2011-01-28 02:33:14 PST
It is nice that the library on Mac OS X would work again in some 4 Beta, but this is really not a solution. 
At the moment, half of my extensions aren't working in 4 and i won't switch until most of them do.

For me still the "best" solution is to keep 3.6.10 with a working library.

I think the only reason why there are not much more complaint about the broken sqlite is that not very much people use the library, what is a pitty, because it is a very nice feature (all those shortcuts etc.).
Comment 66 msth67 2011-02-21 21:37:43 PST
Please,fix this in the upcoming 3.6.14, as of now using the bookmarks library is a real pain,any search takes about forever.
Comment 67 B Laz 2011-02-22 09:57:30 PST
(In reply to comment #66)
> Please,fix this in the upcoming 3.6.14, as of now using the bookmarks library
> is a real pain,any search takes about forever.

see my comment #64 (or orig comment #50 for linux).  Adjust as need for Mac, and the problem is fixed.  I know this problem is officially tagged as fixed, but before I read #50 and updated the sqlite.dll it wasn't for me, and was quite unbearable.  Updating that file fixes it right away, just need to restart FF if it's open when you replace the library file...
Comment 68 Bubba 2011-02-22 10:37:33 PST
Your "solution" (comment #64) is simply not realistic.

99.99999% of FF users are not capable of performing your suggested fix - nor should it be necessary for ANY user to subject themselves to that!

It seems like my FF browser updates itself at least once a week (while I make a cup of coffee, wash the pot, and call a couple of friends...). Surely they can include this fix in one of those updates - sometime this year?!
Comment 69 Ken Brucker 2011-02-22 12:18:37 PST
(In reply to comment #67)
> (In reply to comment #66)
> > Please,fix this in the upcoming 3.6.14, as of now using the bookmarks library
> > is a real pain,any search takes about forever.
> 
> see my comment #64 (or orig comment #50 for linux).  Adjust as need for Mac,
> and the problem is fixed.  I know this problem is officially tagged as fixed,
> but before I read #50 and updated the sqlite.dll it wasn't for me, and was
> quite unbearable.  Updating that file fixes it right away, just need to restart
> FF if it's open when you replace the library file...

And see my comment #51.  I tried the Linux instructions on OSX and it did not work.  Additional magic appears to be required to address this on OSX.
Comment 70 franc 2011-02-22 13:17:03 PST
I want to repeat on this spot, that still 3.6.10 is working perfectly, see my comment #49 ;-)
Don't forget though to uncheck automatic updates!
Comment 71 B Laz 2011-02-22 16:12:44 PST
(In reply to comment #68)
> Your "solution" (comment #64) is simply not realistic.
> 
> 99.99999% of FF users are not capable of performing your suggested fix - nor
> should it be necessary for ANY user to subject themselves to that!
> 
> It seems like my FF browser updates itself at least once a week (while I make a
> cup of coffee, wash the pot, and call a couple of friends...). Surely they can
> include this fix in one of those updates - sometime this year?!
Well since probably only 0.21121167% FF users potentially might even read this, your is moot...

...anyway, I'd call it a work around.  You must hate coffee, or rarely drink it.  There has been no FF release since my post.  Still on 3.6.13.
*v.3.6.13, released December 9th, 2010
*v.3.6.12, released October 27th, 2010
...And it would seem, INS, that the library file would only change if it was updated in the Auto Update/incremental install.  In this case your point also seems moot.

--I'd also like to credit Ralf, as it was his post that nailed it & mine was because of his.

I guess you are using a stale/vulnerable release, or don't often view or search history/bookmarks.  As to the the terrors folks are subjected to, really they seem trivial in comparison to the CPU time eaten if not using trunking, the upgrade sqlite work around, a stale/vulnerable release, or a beta release.

BTW, their supposedly will be four [major] versions released this year (4, 5, 6, and 7!).  Well that's the goal.
Comment 72 B Laz 2011-02-22 16:22:11 PST
(In reply to comment #69)
> And see my comment #51.  I tried the Linux instructions on OSX and it did not
> work.  Additional magic appears to be required to address this on OSX.

Sorry I'm not a Mac person.  All I can think is to build your own library file from the sqlite source code @ http://www.sqlite.org/download.html.
--> http://www.sqlite.org/sqlite-amalgamation-3070500.zip
maybe the script in http://www.sqlite.org/sqlite-autoconf-3070500.tar.gz will give you an idea?  There should be a file named something like sqlite* in the install directory, this is what needs to be replaced.  Surely another Mac person could chime in.

Addionally, http://www.sqlite.org/sqlite-dll-win32-x86-3070500.zip is the now current sqlite for windows as an update to my earlier post's link.
Comment 73 Marco Bonardo [::mak] 2011-02-22 16:24:44 PST
Please, stop the bugspam, bug 618315 is blocking Firefox 3.6.15, with that update this bug will be fixed.
The time was needed to properly test the new SQLite version in 4.0 betas before moving it to the production 3.6 version.

You are currently spamming a bunch of persons that could not be really interested in home-made workarounds and a closed bug.  Move it to a more appropriate newsgroup please.
Comment 74 B Laz 2011-02-22 16:45:57 PST
Well forgive me please.  Although, home made sounds condescending, there hasn't been a fix other than telling folks to use trunked or branched version.  Until the Oreo recipe changes, I'll be eating gradma's cookies.  It is a real problem which you seem to have isolated [and closed].  IMO, there would be no comments here if the bug didn't exist.  

It does seem interesting that you changing the query fixed it.  Since that fix isn't realized by *.13 version, upgrading sqlite fixes it too.  So really the bug seems to be in sqlite, but that was fixed by them too.  

Isn't bug 618315 also closed?  SQLite 3.7.5 in the test queue? 
(In reply to comment #73)
> Please, stop the bugspam, bug 618315 is blocking Firefox 3.6.15, with that
> update this bug will be fixed.
> The time was needed to properly test the new SQLite version in 4.0 betas before
> moving it to the production 3.6 version.
> 
> You are currently spamming a bunch of persons that could not be really
> interested in home-made workarounds and a closed bug.  Move it to a more
> appropriate newsgroup please.
Comment 75 B Laz 2011-03-07 18:49:33 PST
I believe the status needs to be changed here back to OPEN from resolved fixed.  

Heavy CPU load still seen when searching bookmarks or history.  Don't see how this was "RESOLVED FIXED".

3.6.15 exhibits same behavior.  SQLite version [3.7.1.0] shipped seems same as in 3.6.13 & .14.
Comment 76 Daniel Holbert [:dholbert] 2011-03-07 19:13:05 PST
(In reply to comment #75)
> I believe the status needs to be changed here back to OPEN from resolved
> fixed. ... 3.6.15 exhibits same behavior.

No. per Comment 60, FIXED means fixed on trunk, which this is.

> 3.6.15 exhibits same behavior.  SQLite version [3.7.1.0] shipped seems same as
> in 3.6.13 & .14.

That's expected.  Firefox 3.6.15 ended up being an emergency quick release with only a single change.

Patches that were originally targeted for 3.6.15 (like the one Mak mentioned in comment 73) are now targeted for 3.6.16.
Comment 77 Marco Bonardo [::mak] 2011-03-09 02:42:42 PST
*** Bug 639543 has been marked as a duplicate of this bug. ***
Comment 78 Marco Bonardo [::mak] 2011-03-10 03:19:29 PST
SQLite 3.7.4 landed in 1.9.2 branch, so unless this causes bad behaviors (shouldn't) you'll see the fix in one of the next 3.6.x releases (ideally 3.6.16, but could change in case there are other emergency security patches).
Comment 79 Bubba 2011-05-03 06:56:49 PDT
Hallelujah Jesus! Just upgraded to FF v3.6.17 and this has FINALLY been fixed!

I still don't understand how such a CORE usability feature took so long to get fixed, but better late than never I guess.
Comment 80 Marco Bonardo [::mak] 2011-05-03 07:11:25 PDT
verified fixed per comment 79, thanks for your patience!

Note You need to log in before you can comment on or make changes to this bug.