DonationCoder.com Software > Find And Run Robot

Automatic keyword searching in Firefox

(1/1)

Jabberwock:
I was wondering whether it would be possible to automate the keyworded searches in Firefox. I've read the solution posted here:

https://www.donationcoder.com/forum/index.php?topic=15359.0

but it requires configuring each search separately - not very convenient, especially that you have to do it twice (once in FARR and once in FF).

Would it be possible for FARR to gather the FF search keywords and use them automatically as aliases?

ewemoa:
Here are some thoughts regarding this idea:

There are at least two sets of keywords in FF3 -- bookmark ones and search bar ones (stored in different ways).

Bookmark keywords are stored in a file named places.sqlite [1].
This file seems locked while FF is running (at least whenever I've checked, that's what I've found) -- I don't know how to read info from places.sqlite while FF is running [2].  It appears that under some conditions (may be default?), FF backs up bookmarks to a folder named "bookmarkbackups" in a user's profile directory.  This information is stored in JSON format and appears accessible while FF is running -- but it may be out-of-date (perhaps not by much in many cases).

The other type of keywords I know about -- keywords related to search bar searches -- live in search.sqlite.
I have not yet had problems accessing search.sqlite while FF is running (perhaps I've been lucky in my timing).  IIUC, search.sqlite does not contain enough information to create necessary HTTP GET queries -- this information is stored in separate files.  Which files these are may be determined via search.sqlite though :)

That about sums up what I've found so far.  Perhaps other folks have corrections or more useful info regarding these things.  Please share if you do!


[1] Although it seems that FF3 bookmarks can be made to save to HTML, IIUC, keywords don't get saved there :(  Edited: (I haven't verified this myself.) Finally restarted FF and observed the content of bookmarks.html -- I see an attribute for the anchor tag named "SHORTCUTURL" and associated values look to me like keywords.

[2] mouser mentioned a possible work-around -- copy the file, access the content, and possibly delete the copy.

ewemoa:
This page had some nice info (and pointers to info) regarding some of the aforementioned files and directories.

bookmarkbackups\
The bookmarkbackups folder contains bookmarks-(date).json files in Firefox 3.0 and above (daily rotating backups of bookmarks stored in places.sqlite)

--- End quote ---

places.sqlite
The file "places.sqlite" stores the annotations, bookmarks, favorite icons, input history, keywords, and browsing history (a record of visited pages).

--- End quote ---

search.json (FF 3.5 and above)
Cache of search plugin data; used instead of parsing XML files to improve startup time.

--- End quote ---

One possible way of getting at keyword information might be to access bookmarks-(date).json (the latest one) and search.json.  The information contained within might be somewhat out-of-date, but perhaps in most cases, it would be fine.

Edit: Closer inspection of search.json seems to suggest that there are no keywords inside...perhaps it is necessary to interface with search.sqlite afterall...

ewemoa:
I have a proof-of-concept alias thanks to testing and discussions with mouser.

However, now that I have some interactive experience and I've had some time to reflect, I wonder about the value of this idea is in its current form.

To back up a bit, I think what many of us are interested in is having quick/efficient access to searches that are stored/managed in our browsers.  In Firefox (and some other browsers), there is this idea:

  "let the user specify -- via the location bar -- a keyword (which identifies a search) followed by search terms"

I think it's probably not too uncommon for people to edit the content of their location bars at least occasionally, there are shortcut keys to access the location bar, and may be the shortcuts are even some of the better known ones (anyone done a survey?).  The keyword idea doesn't seem too bad in the context of a web browser if you only have a few searches.  I don't think it scales that well though -- coming up with new keywords (and remembering them!) seems uninteresting as an activity in a way similar to coming up with shortcut keys that have not already been used (and remembering them!).

Luckily in FARR, it doesn't seem necessary to use the keywords defined in Firefox -- if you have some already that your fingers memorized, may be it makes some sense to use them -- but why not distinguish searches in FARR using FARR's searching capabilities applied to the names/titles of the searches?  I think this scales better and is kinder to your brain -- perhaps you'll even use the time you're not dreaming up non-conflicting keywords (or not remembering them!) in a good way :)

This is essentially the approach that Keyser takes -- but it doesn't handle searches associated with bookmark keywords (at least not yet) -- it only handles search bar searches.

So in summary, my current inclination is to focus less on keywords (possibly not even bother) and more on names/titles of searches.  The proof-of-concept mentioned above doesn't extract any name/title information so there is nothing implemented toward the revised idea yet.

Any thoughts?


P.S. If there is anyone who'd like to try the proof-of-concept, here it is.  (Contained within should be a README.txt.)

mouser:
great stuff -- I think this tool could also serve as a good starting point for anyone who wants to know how to let farr search a list of items that is dynamically extracted from another program.

Navigation

[0] Message Index