477807 - Add unique ID to bookmark items (like it was in FF2)

Status: RESOLVED WONTFIX

(Firefox :: Bookmarks & History, defect)

Description

[Mozilla Bugs]

In Firefox 2, each bookmark had its own id (although not of ID type, thus not addressable via elem#id but elem[id="id"], but whatever, that's not important) in form of "rdf:#$XXXXXX". Then it was easy possible to explicitly address such bookmark or bookmark folder in CSS to style it.

Say I have folder Foo containing bookmarks Bar & Baz. Now when having the folder on bookmark toolbar, I could have set its CSS to not to display the folder icon, not to display the text, but display the specified icon. Then I had the bookmarks toolbar full of (fav)icons each having its own menu, thus I could have much more items on the bar unlike with default behavior when folder icon and text are shown.

Code excerpt (needs to be customized according to personal bookmarks of the user who is going to check it):

#bookmarks-ptf > toolbarbutton[id="rdf:#$XXXXXX"] label.toolbarbutton-text,
#bookmarks-ptf > toolbarbutton[id="rdf:#$XXXXXX"] image.toolbarbutton-icon
  {
  display: none;
  }

#bookmarks-ptf > toolbarbutton[id="rdf:#$XXXXXX"]
  {
  background: url("_any_16*16_pic_") center no-repeat;
  height: 18px;
  margin: 0;
  padding: 0;
  width: 18px;
  }

In Firefox 3, I can not address certain items directly any longer because of lack of any unique identifier.

I am not familiar with places.sqlite structure, but I'd suppose that eg. the row number (I mean the autoincremented ID) of such bookmark/folder would be the easiest unique identifier which could be propagated to XUL. Furthermore, since it's just number, if say "b" was prepended to bookmark items and "f" to folder items, it could behave like valid ID type, thus could be addressed via #b123 or #f987 syntax to gain the higher position in CSS cascade (and easier CSS coding as well ;-)).

Anyway, I don't quite get the reason why unique identifiers were totally removed (though I understand they won't remain in the old rdf:#$XXXXXX form because of places instead of bookmarks) but not replaced by something equivalent. Please add the unique identifiers back, they are quite important and not only for styling which I shown as the easiest example. Thanks.

Comment 1

[Drew Willcoxon :adw]

As a workaround could you not filter on bookmark titles?

#bookmarks-ptf > toolbarbutton[label="My Bookmark"] { ... }

Comment 2

[Mozilla Bugs]

(In reply to comment #1)
> As a workaround could you not filter on bookmark titles?
> 
> #bookmarks-ptf > toolbarbutton[label="My Bookmark"] { ... }

Hehe, I've expected exactly this reaction... ;-)

It's just _partial_ workaround which works only in trivial cases. I have groups of folders/bookmarks which have the same label but ought to have different icon. Besides, as I mentioned, the unique id is not only for styling, but also for accessing those items from extension eg.

It's highly probable that user will have items with same labels. The more bookmarks user have the higher probability of naming the new one in duplicate. Also it pushes user to think about new and new names in case he wants to rely on label attribute selector. And furthermore imagine renaming of the item - then you'd have to rewrite the label selectors, while id's are constant regardless the name of the item.

Comment 3

[Drew Willcoxon :adw]

We are even, I expected exactly your reaction too... :)

I agree it would be useful for nodes to be ID-addressable in CSS, whatever the kind of ID we'd use.  AFAIK there's no reason we couldn't expose a history node's itemId through the tree view's cell and row properties so that the CSS would be something like:

#myTreeView treechildren::-moz-tree-cell-text(id_1337)

And for content nodes we could set a custom ID attribute.

Is this a regression or enhancement request?  Depends on how you look at it.  Marking as an enhancement, but if anyone disagrees feel free to mark differently.

Comment 4

[Marco Bonardo [:mak]]

with Sync, Import, Restore and moving stuff around profiles I expect ids to be a fragile reference.
We should probably expose GUIDs instead. I fear that they could be a bit slow but actually when Sync will be enabled any bookmark should have his GUID already. So we could also evaluate to speed them up (like a new column for guids rather than an annotation).

Comment 5

[Mozilla Bugs]

It would be great, if this feature could be fixed in ff4 (regardless of the way it's done) when the entire ff3 version ignored this regression.

Comment 6

[Pierros Papadeas [:pierros]]

Hey there,

Sync is delivered :) Do we know if this is fixed?

Thanks!

Comment 7

[Mark Banner (:standard8)]

This seems to have been mainly an extension request for adding the guid onto the toolbar item for easier css.

Since we no longer support full extensions, I don't think we need to do this now. However, if there is a useful case, then it should be worked into a WebExtension API somehow.

Going to mark this as wontfix, and we can consider WebExtension API requests later if they come in.