Arch Linux

no problems here. works for me. no other reports so far.

Are you on x86_64? It may be for 64 bit only.
There may be no reports in this Flyspray task but there is a whole thread of it here: http://bbs.archlinux.org/viewtopic.php?id=78726&p=1

ok, this is an incompatibility issues between sqlite3 and firefox. I expect a new sqlite3 version next week and also a new FF is out. Wait until both have been compiled against each other and report is the issue resists.

I am also experiencing this problem, in Arch64. The upgrade to 3.5.3 alone did not solve the problem. There's a bug report on this at Mozilla here: https://bugzilla.mozilla.org/show_bug.cgi?id=512940

Mozilla has declared the bug invalid because Firefox 3.5.x is designed to run with sqlite 3.6.10 and they do not intend it to be linked to system sqlite. Not even Firefox 3.7, by the way, is being built by Mozilla with 3.6.17 (it uses 3.6.16).

This bug has also been reported in Gentoo, which also links Firefox to system sqlite, rather than use the version packaged with it. In Gentoo people are getting the bug on i686 systems. They've dropped system sqlite for the time being. See: http://bugs.gentoo.org/281695

Oops, I meant in Gentoo they're seeing the bug in i686 and amd64 systems.

Is it possible to link firefox not to system sqlite but, perhaps static, to a separately provided sqlite 3.6.16 version?

You can modify XULRunner from ABS to use the built in sqlite.
Comment out the system sqlite line in mozconfig, fix the md5sum array in the PKGBUILD, compile and enjoy.

Thank you Andrew Mellor, your solution with the rebuild of xulrunner works for me too. Before that, I tried sqlite 3.6.18 (only a quick edit of the PKGBUILD) with no success.

I'm using Icecat, but I did the same thing with xulrunner, with help from the icecat packager and it also solved the problem for me.

Glad to see that my solution works. From the Firefox bug report it seems that they will not fix it any time soon.

Recompiling XULrunner solved the problem here, too.
Thanks!

BTW: Shouldn't we provide such a package until the Mozilla folks decide to use a sufficiently recent sqlite again?

I cannot confirm it in any way here under Xfce. When it crashes when a file dialog should popup maybe your desktop environment is the reason for the crash. Or your local db is damaged. Maybe try with a new one. I'm also just building a new sqlite3 release.

I don't know. It seems like the bug is pretty well established having to do with system sqlite not being the right version as intended by Mozilla. Here's the Mozilla bug report again:

https://bugzilla.mozilla.org/show_bug.cgi?id=512940

And here's a bug report from Gentoo finding the same thing. One person in that report figured out that it seems to have something to do with how bookmarks are organized. But again, they disabled system sqlite as the solution.

http://bugs.gentoo.org/281695

Also the crash doesn't happen necessarily when the dialog should popup. For most people it seems to happen when they try to expand folder view in the bookmark dialogue.

If you can reproduce it try a xulrunner/FF/sqlite debug build to help finding a solution to get it work with a recent sqlite version.

Because not many people seem affected in ArchLinux Jan and me don't have the intention to switch back to make use of internal outdated sqlite.

Jan, you should think about compiling xulrunner with internal sqlite until Mozilla guys fix their broken code. I can't do anything in the sqlite3 pkg.

Your choice. Removing myself here.

I can also confirm this bug. After a few weeks of this bug's existence, it is safe to assume this is the Arch bug rather than Firefox one - Mozilla devs have clearly stated which version of sqlite3 should be used for firefox/xulrunner (if we're not using the internal one), which means it is neither firefox, xulrunner, nor sqlite3 bug.

Anyway - the bug reproduces on x64 AND i686, both KDE and GNOME.

And from mozilla bug report :
If distributions want to use system libraries, they can. I sure hope they run
our unit tests before hand though to ensure that the things we have automated
tests for are at least going to run as we expect them to. In the past, I know
distributions have not done this much, and I'm not sure if this has changed.

So if the tests haven't been done (and apparently they either haven't, or you guys actually *want* your Firefox to crash every time a user tries to bookmark a page), is there really an excuse for the xulrunner using an incompatibile version of sqlite?

Well, same here, I'm on x64... I only see the problem, if I have a lot of bookmarks and folders, after creating a new profile without folders and less than 30 bookmarks everything's fine. And I can confirm that recompiling xulrunner with internal sqlite fixes the problem for good. Since the mozilla devs are planning to use an outdated sqlite for the next versions too, can we pretty please get a xulrunner package with internal sqlite?

+1 to that! I don't think it should be a problem to recompile it for the official repos...

+1, too. It appears to be mandatory now.

+1, I'm waiting since a month for an arch-solution.

+1, I also agree. It looks like the way Mozilla has their development cycle organized, they will always be using an older version of sqlite. It really seems to me that there is just a fundamental conflict here between the Arch philosophy and the Mozilla way of doing things. So there's no good solution that doesn't require someone compromising on their philosophy. And sadly I just really can't imagine Mozilla budging on this, since Arch for them is just one of many many distributions they deal with.

Actually, the way I see it, Mozilla would be compromising on their philosophy much more than Arch, since their standards are set quite strictly, and testing Firefox against each and every build of sqlite (many of them being unstable and buggy) would require much more work than just recompiling xulrunner with the internal sqlite.

On the other hand, there are many Arch users which have sqlite installed just because it's a dependency of nss and redland; the majority of Linux (or any other OS) users don't code python (or don't code at all), and don't listen to their music via MPD (alright, so there is Amarok, but still), so it wouldn't be much of a loss to them.

I am aware that this is not completely Arch philosophy, since the solution is not the most elegant once one realises that they have more than one sqlite on their system - a setup which, apart from not being the most elegant one in the universe, uses up quite a bit more resources once you fire up both Firefox and, say, Amarok. (thirty-fifteen)
However, we do have a situation where the Arch philosophy has failed, since it rendered one of the most used applications half-useless. (Let's face it, apart from Opera, there are few web browsers which are comparable to Firefox.)

And there's another issue worth mentioning. If Arch stays persistent with this philosophy, and somebody manages to patch xulrunner and/or sqlite3 to work *now*, this will not solve the problem in the future. Firstly, sooner or later there will be another version of sqlite and/or xulrunner/Firefox which will again prove incompatibile, and further patching will be required. And secondly, this will render Arch users unable to report bugs to Mozilla or sqlite developers, since we won't be using the vanilla versions (which *is* the Arch philosophy, so that the problems which arise with the applications can be reported directly to their devs).

AND, if we're using vanilla packages already, then let's use the true vanilla packages, together with the "vanilla" configurations recommended by the app devs. If Mozilla recommends using the internal sqlite implementation, I'm betting they have a bloody good reason for it (as we can see from this particular example).

I already stated my +1, but I just felt like expressing my opinion.

It's true, as I noted above, that Mozilla has already ruled this bug invalid, because it arises from using Firefox in a manner that it was not intended to be used.

"(Let's face it, apart from Opera, there are few web browsers which are comparable to Firefox.)"

Arora or Midori, try them. If you don't mind unsupported, get chromium. Neither of these browsers have this problem.

That may be so. However, this is not the solution to the Firefox problem.
And besides, many users find Firefox unmatched because of the plugins (aka add-ons) which give the functionality no other browser has.
Xmarks, StumbleUpon, NoScript, Greasemonkey are just a few of them.

Well, frankly I don't understand these comments "just use another browser". If I wanted to do that, I wouldn't bother to create an account to share my experience. My array of plugins make my life safer and easier in the interwebs, therefore I don't see a point why I should do it the hard way. If you know how to use greasemonkey you really don't want to miss it.

We have a confimed bug here, as well as an admittedly not so elegant solution. As long as nobody finds a better one, I suggest we use it. Just letting it sit here without doing anything is imho not the way to go for a core application. And it won't solve itself, the mozilla devs already confirmed that they will use outdated sqlite versions in future releases.

I know how to compile a working xulrunner, therefore I have found my workaround. I'm seriously concerned though, that a botched firefox, and that's the impression a new user gets, will hurt the reputation of Arch pretty bad.