It would be cool if you could make any bookmark folder into a bookmark group from the bookmark folder properties window.

The folder context menu is where I expect to find this capability. Do you not want it there? If not, please explain. Also, the ability to translate back should be provided. Should I file a new bug for that?

If the folder we are applying the translation to already contains a bookmark group, I think we should nest bookmark groups similarly to folders. When opening, the list could be flattened, and opened in seperate tabs. This would make it easier to reuse groups of bookmarks, especially if we ever get bookmark aliases working.

I like this idea Adding myself to CC:

I don't think this is a good idea. It should be possible to open _any_ bookmark folder as folder and group, without the need to 'convert' or 'duplicate' a given folder. Doing it like this will be a major advantage for the "mom" users out in the field. Why make things more complicated than they already are? Why not ad some code to support: "Open Bookmarks Folder as Group" ? FYI: this is the way MultiZilla solved this problem, months ago now.

If I'm understanding comment # 4 correctly, then I wholeheartedly agree with the author. There is no real requirement for the existence of group bookmarks as differentiated from normal bookmarks. I've used a tabbed-browser add-on for IE for a while now, and it has something similar to "Open Bookmarks Folder as Group", except they call it "Open all favourites". This item appears as the first item in any bookmarks folder when using the favourites/bookmarks dropdown menu. Choosing it opens any bookmarks in the current bookmark folder, in new tabs. This does away with the need for group bookmarks, and it means that you can just move bookmarks into and out of (say) a "Check the morning news" folder. This is much nicer (to use, as well as implement I would imagine, since there it does away with a whole special category of bookmarks). It would also simplify "Manage Bookmarks" tool I imagine too, plus it also does away with the need for the "File as group" tick box when adding a bookmark. Plus, as comment #4 pointed out, this would ensure there is no duplication / conversion / synchronisation going on between 'normal' bookmarks and 'group' bookmarks. I've used this kind of thing for literally years now, and it really does work very well, as well as being simpler.

You can already move bookmarks in and out of bookmark groups, I do it all the time. However, the great feature of bookmark groups which other suggested mechanisms don't allow is the ability to single click the bookmark in the sidebar and have it open all the tabs. I don't use the Bookmarks menu, because it requires too many mouse movements.

Re comment #6: I can see that clicking on a group bookmark in the sidebar could be a handy setup that could work well whilst keeping the number of mouse clicks low. However, couldn't the sidebar use the same possible idea as the bookmarks dropdown menu, and have an inbuilt first item in any folder that means "open everything in this folder"? Alternatively, if screen space is at a premium, how about instead of having an extra item appear, a middle mouse click (say) on a folder could equate to the same "open everything in this folder" action. That way you get the generality of folders, but the power of groups (and there's no need to move anything around at all once a setup has been reached that the user is happy with). Thoughts?

I don't have my bookmark groups open, if I did they couldn't all fit on the screen at once. Also, I don't have a middle button. What is wrong with the current behaviour? Note that this really should be discussed in another bug.

See also bug 141619, "[RFE] Treat bookmark folders as bookmark groups.", about eliminating the "bookmarks group" concept in favour of being able to open all bookmarks in *any* folder in new tabs.

Re comment #9 : Thanks, yes, that's what I had in mind. Re comment #8: Essentially, I don't see why there should be any distinction at all between bookmark groups and folders. What distinction there is seems quite limited and arbitrary to me. Consider: The current idea seems to be that folders are just containers - they store bookmarks, bookmarks groups, and other folders. However, they themselves can't currently be opened as a group. Furthermore, they can be expanded in the bookmarks dropdown menu, as well as in the sidebar. Bookmark groups also store bookmarks inside them, as well as folders, and also other bookmark groups. So, in other words, they too are containers. However, bookmark groups have the property that they can open every bookmark directly underneath them in one go. Furthermore, bookmark groups cannot be expand using the bookmarks dropdown menu, but they can be using the sidebar. Why is there such an arbitrary and minute distinction? I don't see why they shouldn't be identical, interchangeable, undistinguishable, one and the same. In other words, everything that can be done with a group bookmarks should be able to be done with folders (such as opening all it's immediate sub-contents at once), and everything that can be done with folders should be able to be done with group bookmarks (such as expanding it's contents in the bookmarks dropdown). This might seem to be unrelated to the current bug, but it's really not. Once there are indistinguishable, there is automatically no requirement to convert between them, and therefore there would be no requirement for the conversion behaviour requested in this bug.

I found this bug because I was going to write an enhancement request to be able to right-click a folder and make it a group and vice-versa. Taking that action also implies several additional UI changes - like the aforementioned properties window addition and some tweaks of the menus(maybe bug 156153). When bookmark groups first got the UE design treatment this ability was a fundamental part of the plan - but somehow went missing. Two questions arise: 1. Is it worth adding a bunch of UI and behaviors vs. simply making BM Groups and folders indistinguishable as mentioned earlier in this bug? 2. What happens when one opens a BMGroup that contains bookmarks and another nested folder? Has anyone seen this in multizilla or the IE add-on? nominating for nsbeta1. I believe solving the problem of seamless integration of Bookmark Groups into overall Bookmarks Management is the final piece in this great feature (tabs+ bookmark groups).

1. no, it's not worth the time at all, if you ask me 2. we, multizilla, have two ways of handling the BMgroups, see my two screenshots

With the first set (bookmarks menu/button) you cannot only see the content of the group but it is also plain easy to select only one bookmark, and that seems to be used a lot in MultiZilla. The second set filters the folders out of it and you can't select bookmarks, but that is because this is called "Load Tab Group" and so completely different to plain bookmarks. note: It's really easy to change the template, even I did it, but the JS functions needs to be changed also, just to let you know. Q: why should we hide the content of a bookmarks group to the user? What is so handy about that 'feature'? "I believe solving the problem of seamless integration of Bookmark Groups into overall Bookmarks Management is the final piece in this great feature" What about Loading Tab Groups at startup, like in MultiZilla?

I'm completely in favour of HJ's UI, with the one caveat that I'd put "Open The Folder As Group" at the *bottom* of the bookmark list rather than at the top. That way you have to explicity move the mouse cursor to get to it. (If people have bookmark folders that haven't changed in a while and they've "trained" themselves to always open a bookmark within by automatically moving a certain distance to it, putting the "Folder As Group" won't interfere with this.)

Nav triage team: nsbeta1+/adt2

It seems to me that the following would be a suitable compromise: 1) Folders and Groups are one and the same entity. 2) Folder properties dialog contains a checkbox labelled "Treat as Group". 3) If the box is checked, then the default behaviour of a left click on the folder in any of the various dialogs (with the exception perhaps of 'Manage Bookmarks' dialog) is to open a group of tabs, and the associated icon is the groups icon. If the box is unchecked, treat the folder as a folder in the usual way. 4) An accelerator key could be used to invoke the alternate behaviour (eg CTRL Left click). However, there is one fundamental difference between Groups and Folders, Groups are essentially bottom level elements, whereas folders can contain subfolders. Hence, some additional constraints would be: a) The checkbox would be greyed out on a folder which contains subfolders. b) Subfolders cannot be added if the checkbox is checked. Alternatively, subfolders are permitted, but must be ignored when opening a folder as a group. This is probably preferred.

A. Is it worth adding a bunch of UI and behaviors? imo, no. B. simply making BM Groups and folders indistinguishable as mentioned earlier in this bug? imo, this makes more sense. 2. What happens when one opens a BMGroup that contains bookmarks and another nested folder? I'd just ignore nested folders. Oh, i'd also drop the word 'groups' and just have "Open these bookmarks as tabs".

FWIW: If the decision here is to make "BM Groups and folders indistinguishable" then this bug is really just a dupe of bug 141619.

This bug is just about adding a checkbox to the properties window, nothing more.

> This bug is just about adding a checkbox to the properties window So this is NOT about making them indistinguishable. The Bookmark Manager currently considers Bookmark Groups and Bookmark Folders to be separate entities (look at the recently checked in code for help text). For them to be considered "indistinguishable" - as per comment 19 (point B) that distinction would have to be dropped. (Bookmark Groups, as separate entity, removed altogether.) But more to my original point in comment 20: If a fix for bug 141619 were to be checked in - would this bug then become obsolete? (And/or vice-versa - are they mutually exclusive?) Or would there be some reason to continue with a "checkbox" implementation anyway?

*** Bug 167414 has been marked as a duplicate of this bug. ***

reassigning

bug 174778 makes more sense then this.

This is blocked by a bug in the XUL template builder. The only difference between a folder and group is that the latter has the NC:FolderGroup property set to true. The problem here is that we have multiple rules in bookmark templates and one of them is checking for NC:FolderGroup. So once we change the property it should match a different rule, but that actually doesn't work correctly (the UI is not rebuilt correctly). I suspect it may be related to these comments: http://lxr.mozilla.org/seamonkey/source/content/xul/templates/src/nsXULTemplateBuilder.cpp#421 http://lxr.mozilla.org/seamonkey/source/content/xul/templates/src/nsXULTemplateBuilder.cpp#512 I'll ask waterson what he thinks about it.

adt: nsbeta1-

Based on comment 21, and after reading the whole bugs, I'm not sure of the best solution(s), but you may see related bug 141619 comment 33.

(In reply to comment #26) ... > I'll ask waterson what he thinks about it. > What did he ever say about it anyhow?

I can't remember what he said and unfortunetely I lost my IMAP folders at that time (July 2003). But I still think it has something to do with this comment: http://lxr.mozilla.org/seamonkey/source/content/xul/templates/src/nsXULTemplateBuilder.cpp#512

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420