User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 It is hard/impossible to set bookmark/folder/separator id from outside of the bookmark component. IMHO, it's time to redesing the whole bookmark APIs and this is the "must-have" feature in the long run. Reproducible: Always Steps to Reproduce: Actual Results: e.g. nsIBookmarksService::createBookmark(aName, aDescription, ...) Expected Results: nsIBookmarksService::createBookmark(aID, aName, aDescription...)

/** * @param aID If this string is null, empty, or dupe, * the resource URI will be unique random chars. */ and its bubbles.

I don't know why this is needed. I'd also let vlad make the call on breaking the API.

(In reply to comment #2) > I don't know why this is needed. > I'd also let vlad make the call on breaking > the API. Thanks for the comment. OK, it's time to start lobbying to swift passage of a bill. There are a lot of RFE bugs to make mozilla bookmark life happier. The biggest probolem is it's impossible create RDF:Seq without accessing mInner datasource. var hds=RDF.GetDatasourceBlocking("rdf:history"); var bds=RDF.GetDatasourceBlocking("rdf:bookmarks"); RDFCU.MakeSeq(hds,RDF.GetAnonymousResource());//No problem. RDFCU.MakeSeq(bds,RDF.GetAnonymousResource());//Throws NS_ERROR_FAILER This is not only a scripting issue. Reproducible with C++ components. However, I don't think this problem is a bug to be fixed. We don't need too many ways to create a bookmark folder. As long as the api can create bookmark folder nicely, we can live without these crappy RDF:Seq. API is not nice enough for bug 55057, bug 78072,(seamonkey) etc. Creating consistently identified resouce is very important for merging 2 data into 1. And I guess users will keep asking import ***bookmark featrue one after another. This is the minimal, most modest, does-not-hurt-anyone hallelujah patch.

Please discuss/get review from vlad on this. As a note, there's some comments in bug 55057 about support for various firefox attributes/functionality, including embedding favicons as data: URIs.

If you're still looking to get this in, please request review from vlad, I've already asked that you do so twice. However, please keep in mind that part of the 1.5/2.0 plans are to rewrite large chunks of bookmarks code and drop the existing storage format fun.

Comment on attachment 167717 [details] [diff] [review] patch v1 moving review request

Comment on attachment 167717 [details] [diff] [review] patch v1 The patch will break if a non-bookmark resource with the given ID exists; I also don't think that having the semantics of "existing ID causes reuse" makes any sense for methods named create*(..). As mconnor said, there will be a massive rewrite of the bookmarks goop at some point in the not too distant future; I'd rather not muck up the current broken service API even more, as we'll be stuck supporting it at least initially.

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change

Is this bug still relevant with the change to Places and SQLite on the trunk?

This interface no longer exists, so this bug is now INVALID.