Determining any disabled search plugins

[Andrew Conkling]

Hello,
I'm looking to help out with the Deskbar applet for GNOME [1], a
project that, among other things, pulls in Firefox search plugins to
give a way of beginning an internet search outside of Firefox.

At the moment, it is unable to determine if any globally-installed
Firefox search plugins are disabled. Can anyone point me to where this
information is kept? I've looked in about:config and my profile
directory and the author of the Firefox code has grep'ed the Firefox
source, but nothing has popped out.

Any help would be most appreciated!

[1] http://raphael.slinckx.net/deskbar/

Cheers,
Andrew Conkling

[Gavin Sharp]

Andrew Conkling wrote:
> At the moment, it is unable to determine if any globally-installed
> Firefox search plugins are disabled. Can anyone point me to where this
> information is kept? I've looked in about:config and my profile
> directory and the author of the Firefox code has grep'ed the Firefox
> source, but nothing has popped out.

What do you mean by "disabled"? Which versions of Firefox are you
looking to support?

Gavin

[Andrew Conkling]

Hi Gavin,
Sorry, I suppose that's unclear usage. I mean a plugin (most likely a
default one) that:
* exists in the global installation directory (over which a user may
not have permissions), e.g. /usr/share/firefox/searchplugins.
* does not exist in the user interface because the user has removed
the search plugin via the "Manage Search Engines" UI

At the moment, the Deskbar code just looks to see which plugins are
available in the global directory and the user's profile directory.
This is only because no one on the project is sure where to find out
which a user has "removed" from the browser.

As for the versions, I'm not sure. I know that the current version
works for 2.0, which would probably be the developers' main focus.

Thanks,
Andrew Conkling

[Saravanan]

> This is only because no one on the project is sure where to find out
> which a user has "removed" from the browser.

I could see search plugin data are stored engine_data table of
*search.sqlite* sqlite db in the user's profile folder. You may have
to dig deeper to find more info.

Thanks
Saravanan

[Gavin Sharp]

Andrew Conkling wrote:
> * does not exist in the user interface because the user has removed
> the search plugin via the "Manage Search Engines" UI

OK, so you're working with Firefox 2. In that case, when you remove a
shipped-by-default engine using the UI, the search service sets a
"hidden" flag that causes the engine to not be displayed. This metadata
is stored in the user's profile directory in an SQLite database named
search.sqlite.

Getting this data from outside of the Firefox process probably isn't
trivial... you can run "SELECT engineid FROM engine_data WHERE name =
'hidden' AND value = 1" against the database to get a list of disabled
engine IDs, if you're up to reading the file directly. Engine IDs are
either a full path to the file, or an abbreviated relative path with a
[app] or [profile] prefix to indicate the application or profile
directory (e.g. "[app]/google.xml" or "[profile]/eBay.xml").
Alternatively, you could obtain the data from an extension to Firefox
via the nsIBrowserSearchService/nsISearchEngine interfaces.

Hope this helps,
Gavin

[Gavin Sharp]

Gavin Sharp wrote:
> Getting this data from outside of the Firefox process probably isn't
> trivial... you can run "SELECT engineid FROM engine_data WHERE name =
> 'hidden' AND value = 1" against the database to get a list of disabled
> engine IDs, if you're up to reading the file directly.

I should add that it probably isn't a good idea to try to read from the
database file directly while Firefox is running.

Gavin

[Gervase Markham]

Gavin Sharp wrote:
> I should add that it probably isn't a good idea to try to read from the
> database file directly while Firefox is running.

I don't know much about SQLite but, unless it writes inconsistent data
to disk, surely it's safe to read, as long as you don't try to write?

Gerv

[Mike Shaver]

As with pretty much any other transactional system, reading can
trigger a journal replay if the database is in a certain state (such
as after a crash), and having two journal replays happen at the same
time is bad times.

Mike
(and stop calling me shirley)

[Gervase Markham]

But how can the system detect you've done a read? You are not connecting
to the in-browser SQLite engine and saying "please read this data for
me" (as I understand it, you can't; SQLite is single-client); you are
reading/copying a file on disk and pointing your own SQLite engine at it
and saying "read this".

If Firefox is running, how can the SQLite implementation inside it tell
that you've read the file from disk to give it to another copy of
SQLite? Does Windows, for example, even _store_ last-read-time?

Gerv

[Saravanan]

On 2/19/07, Mike Shaver <mike....@gmail.com> wrote:
> On 2/19/07, Gervase Markham <ge...@mozilla.org> wrote:

> As with pretty much any other transactional system, reading can
> trigger a journal replay if the database is in a certain state (such
> as after a crash), and having two journal replays happen at the same
> time is bad times.
>

According to Sqlite FAQ <http://www.sqlite.org/faq.html#q7> read
operation from multiple processes are safe. But only one process can
write to sqlite at a time. But I am not sure about the case Mike is
talking about.

Saravanan

[Mike Shaver]

On 2/19/07, Gervase Markham <ge...@mozilla.org> wrote:
> But how can the system detect you've done a read? You are not connecting
> to the in-browser SQLite engine and saying "please read this data for
> me" (as I understand it, you can't; SQLite is single-client); you are
> reading/copying a file on disk and pointing your own SQLite engine at it
> and saying "read this".

Yes, and that sqlite engine will look for a journal to replay on open,
as it must in order to preserve ACID semantics. Replaying the journal
modifies the database (perhaps obviously) and can collide with writes
from another process.

(This is my understanding from the sqlite list and cursory examination
of the source.)

Anyway, this discussion is now out of scope for this list. If you
have more questions about database internals, feel free to mail me or
the sqlite list privately.

Mike

[Andrew Conkling]

On 2/18/07, Gavin Sharp <gavin...@gmail.com> wrote:

> Andrew Conkling wrote:
> > * does not exist in the user interface because the user has removed
> > the search plugin via the "Manage Search Engines" UI
>
> OK, so you're working with Firefox 2. In that case, when you remove a
> shipped-by-default engine using the UI, the search service sets a
> "hidden" flag that causes the engine to not be displayed. This metadata
> is stored in the user's profile directory in an SQLite database named
> search.sqlite.

A bit tangential, but why is this info stored in a sqlite database and
not in, say, about:config?

[Gavin Sharp]

Andrew Conkling wrote:
> A bit tangential, but why is this info stored in a sqlite database and
> not in, say, about:config?

Because there are various other attributes associated with search
engines (order, alias, updateURL, etc) that made using prefs
troublesome. Maintaining pref trees when elements are potentially being
removed/added is a pain, adding/removing a row to a DB is easy.

Gavin