Do no longer brings up firefox bookmarks in search results

It's a firefox3 vs firefox2 issue. We can't do a proper Firefox3 plugin yet
because mozilla is still changing the way plugins (places) are stored on
disk. If you export your Firefox3 bookmarks to
~/.mozilla/firefox/YOURPROFILE/bookmarks.html everything will work as usual.

Thanks Dave! That worked. Hopefully Mozilla will solidify how they do their bookmarks so we can have this all done automatically again.

Mike, would you please do me a favor and post this tip for Firefox3 users on
the plugin wiki page for the Firefox plugin?

Closing since this is not Do related.

I have the same problem, but enabling

~/.mozilla/firefox/YOURPROFILE/bookmarks.html

does not work at all...

Still this error when starting gnome-do and no firefox results:

Firefox.PlacesItemSource "Firefox Places" encountered an error in UpdateItems: System.NullReferenceException: Object reference not set to an instance of an object
  at Mono.Data.SqliteClient.SqliteDataReader.GetString (Int32 i) [0x00000] in <filename unknown>:0
  at Firefox.PlacesItemSource+<LoadPlaceItems>c__Iterator3.MoveNext () [0x00000] in <filename unknown>:0
  at System.Collections.Generic.List`1[Firefox.PlaceItem].AddEnumerable (IEnumerable`1 enumerable) [0x00000] in <filename unknown>:0
  at System.Collections.Generic.List`1[Firefox.PlaceItem]..ctor (IEnumerable`1 collection) [0x00000] in <filename unknown>:0
  at System.Linq.Enumerable.ToArray[PlaceItem] (IEnumerable`1 source) [0x00000] in <filename unknown>:0
  at Firefox.PlacesItemSource.UpdateItems () [0x00000] in <filename unknown>:0
  at Do.Universe.Safe.SafeItemSource.UpdateItems () [0x00000] in <filename unknown>:0 .

I had the exact same stack trace as above. It turns out that just checking for null before accessing a bookmark title solves the problem. (see attachment)

The proposed patch, solves this problem in Lucid and Maverick.
Attached, you can find patched firefox.dll.
Just replace the file in /usr/lib/gnome-do/plugins.

thanks stephan and sterios, this worked for me

after upgrading firefox to version 4.0 (ubuntu 10.04, upgrading with ppa: mozillateam/firefox-stable) gnome-do is not working again.

terminal:
Firefox.PlacesItemSource "Firefox Places" encountered an error in UpdateItems: Mono.Data.SqliteClient.SqliteSyntaxException: file is encrypted or is not a database
(...)

???

After upgrading to Firefox 4 on Ubuntu 10.4 Gnome Do 0.8.3.1 no longer lists any of my Firefox URLs.

Same problem encountered with Gnome-Do on Ubuntu 10.10 (32-bit.) Complete URLs must be typed in, as bookmarks are no longer searched.

This Firefox.dll works for me on Ubuntu 11.04 (32-bit). Unfortunately I didn't see the patch by Stephane earlier, so I wrote a new one myself which does more or less the same thing.

Put the file in /usr/lib/gnome-do/plugins

This is my actual patch.

We really need a better way of extracting data from Firefox than relying
on them not changing their database schema. This will be particularly
important with the new, faster release cycle FF is using.

Possibly a Firefox extension + the browser DBus bridge could work.

Hm, maybe I didn't understand your proposal right, but wouldn't this mean that Firefox needs to be running in order for the plugin to work? This would break the main way in which I use the plugin - to start Firefox with a specific page in mind.

Here is another patch that fixes a related problem (as well as the original bug) - Bookmarks with no set title didn't show up in gnome-do by just typing. With the patch, if a bookmark doesn't have a name, the title of the page is used as a name instead (or the page url if the page doesn't have a title). I think this was the originally intended behavior.

On Tue, 2011-07-05 at 01:31 +0000, Martin Florian wrote:
> Hm, maybe I didn't understand your proposal right, but wouldn't this
> mean that Firefox needs to be running in order for the plugin to work?
> This would break the main way in which I use the plugin - to start
> Firefox with a specific page in mind.

That's a good point; it makes that particular idea non-workable.

I still think it's a bad idea to access Firefox's private database
ourselves.

I'll check out your patches and see if they work on the Firefox 5 that
Oneiric has, though.

While the firefox.dll file has worked for me in the past, I'm now running Aurora 12.0a2 (2012-02-01), which breaks the Gnome-Do extension again.

It would seem that a longer-term solution could be realized by having the user locate the specific file FireFox uses to store bookmarks. This way updates will no break compatibility, since the user would merely have to point the plugin to another bookmark file in the .mozilla folder.

It's not (just) that the specific file that Firefox uses to store bookmarks, it's that the format of the file Firefox stores bookmarks in changes.