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.

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.

Some discussion: http://forums.mozillazine.org/viewtopic.php?p=9964421#p9964421 (as well as the 2 posts directly above it)

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

for me, it is both. but history is considerably slower. I have about 40 days of history right now

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.

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.

Thanks for your confirmation Marco. I am working on that now. Hopefully I can find a window sometime tonight for you.

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.

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.

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

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");

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

(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.

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.

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.

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

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.

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.

(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.

This will either be fixed by bug 598306 or by bug 599641. Drivers should set blocking flags as they see fit.

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.

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.

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 on attachment 482807 [details] [diff] [review] remove LENGTH check r=sdwilsh. I suspect we may want to take some patch for branch here too.

(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

ugh there is another entry in mDBGetTags, I'll remove it as well.

(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)

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.

(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.

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.

PLEASEEE release this fix ASAP!

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.

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.

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.

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 !

patience please, it will be fixed pretty soon.

(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.

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.

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

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?

(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).

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.

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.

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.

Just use 3.6.10, it works. But it is not possible to just use the dylib of 10, it wont work in 13.

Yes, this is a HUGE usability issue! If you're used to using tags it's almost unbearable.

This is very very right. I suffered so much i nearly thougt to switch to chrome for mac.

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

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.

@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?

(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.

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.

(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).

(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.

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??

(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.

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...

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.).

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.

(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...

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?!

(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.

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!

(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.

(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.

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.

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.

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.

(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.

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).

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.

verified fixed per comment 79, thanks for your patience!