Currently for the Addon-SDK, we have the Places API for Firefox and would like support to do the same for Fennec as well. Talking with Wes, seems like something even as simple as exposing sqlite queries would allow us to create a similar interface for our API. What's currently supported in the SDK Places API: * getFavicon(url) * CRUD operations for bookmarks/folders/separators (for bookmarks, properties like title, URL, tags, its parent, index within its parent, last updated) * Tags: Add, removing tags from bookmark items * Querying Bookmarks -- we have querying bookmarks and history as two separate functions, although with a similar API. We have a subset of the places API for query objects (which are OR'd together), with an options object. Supported query parameters are: * query: A string that fuzzy matches the URI, title, or any of its' tags * tags: Array of tags. These are AND'd together. * group: All bookmarks that live under this parent folder * url: A string indicating what URLs are acceptable results (and using String url: A string indicating what URLs are acceptable results. We use different combinations of `uri`, `uriIsPrefix`, `domain` and `domainIsHost` of the nsINavHistoryQuery (https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsINavHistoryQuery) to create easy to use strings to specify what kind of URLs are within range: "mozilla.com" matches any URL with 'mozilla.com' as a host name "*.mozilla.com" matches any URL with 'mozilla.com' as a host, or any subdomain of mozilla.com "http://mozilla.com/" matches only the URL 'http://mozilla.com/' "http://mozilla.com/*" matches any URL that begins with 'http://mozilla.com/*' We support a subset of nsINavHistoryQueryOptions (https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsINavHistoryQueryOptions) for bookmark searching, only sorting and count/limit of results. * Querying History - Similar to bookmark querying, where we accept `n` query objects, and one options object. The options object is the same as bookmark queries, and the query objects take: * url: (same pattern matching magic as the bookmark querying) * query: same query string (matches URL, title) as bookmark querying * to/from date ranges: time range of when the page was last accessed --- Most of this could probably be done with just an exposed querying method of the sqlite entry, which I think would be the least amount of work on the platform side. It seems like quite a bit of work to have Fennec have full parity for Places API on the platform API, but maybe this is a better approach? Either way, any access to the database would be huge in terms of supporting Fennec for mobile add on development, and something we'd love to have.

Something else that we are implementing for the SDK on the Firefox platform is an observer -- detecting when a bookmark is added, removed, changed, etc., and same for history (on visit, removal, etc.). If this is possible to add as well, it'd be awesome.

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #1) > Something else that we are implementing for the SDK on the Firefox platform > is an observer -- detecting when a bookmark is added, removed, changed, > etc., and same for history (on visit, removal, etc.). If this is possible to > add as well, it'd be awesome. This is certainly possible. In fact, Android will manage a good part of this for us (if we care to have Android manage it). There is an example of threading an Android notification back to Gecko at http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/SharedPreferencesHelper.java#185 Threading a ContentProvider changed notification will look quite similar. Notifying on history *visit* might be a little different, since that doesn't necessarily touch a ContentProvider.

It would be great to have basic places/* support, as it could be used to implement a simple synch add-on where the 1.5 synch server would be too heavy a tool to implment (e.g. as an app for owncloud while we figure out how to port the synch server to pure js). I am willing to write tests, test the code, provide simple bug fixes and write documentation, if someone could implement a basic version for places on Android.

On a little bit of a tangent: It's my experience that 'simple' sync systems, and ones built as add-ons, don't really work -- there's a lot of intrinsic complexity in multi-device data manipulation. It's either not simple or it's buggy. I don't know offhand if the Add-on SDK API exposes everything you'd need to build a sync system -- e.g., management of roots, GUIDs, modified times, queries and other record types, access to individual history visits, etc. etc. That effort is likely better spent in porting the existing ownCloud server to Sync 1.5, and thus getting support for every platform automatically.

Richard, this comment could be from an old school Microsoft engineer suggesting NoSQL databases can't be good because storing data is not that simple and other solutions than SQL must be buggy ... I think the current server is great for many users, but too big (maybe even bloatware) for a use case of 3-5 users per server. I thought Mozilla is about giving users the opportunity to build (even ****) add-ons. I am simply asking for the implementation of this api feature on Android and I am willing to help with the tedious tasks of testing and documenting code as I am not familiar with Firefox's datastructures on Android.

I'm speaking as someone who's been fixing bugs, all the way from coding errors through to fundamental protocol flaws, in Firefox Sync clients for more than four years. Sync, as you might know, started life as Weave -- a simple sync add-on. And it's been breaking people's bookmarks and losing password changes ever since. It would be wrong of me to give you encouragement that this is a problem that admits a simple solution without abandoning a lot of desirable properties (such as the ability to browse without a live connection to the server). You're welcome to ignore me, of course. Whether or not I think your add-on idea is worth pursuing is largely independent from whether or not this bug will receive attention; it's something we want to do at some point (otherwise the bug would have been resolved), but shipping software is about tradeoffs, and there's a lot of other important work to do. Mozilla is about protecting and enabling access to a free web. Sometimes that means prioritizing add-on support, and sometimes it means concentrating on other things.

Sorry Richard, I - obviously in contrast to you - have work to do and I can't discuss the business case with you any longer. If anyone is interested in the technical discussion about what could be implemented how and what specs, tests, etc. are missing, please let me know.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.