since bug 317878 is fixed now, we should be able to implement this. This isn't completely thought out, since its 5 AM, but here's the general idea: Maintaining and editing a set of links as multiple homepages is just parallel UI that we really don't want to implement. The current solution isn't very clear, and requires managing a single textfield in the Options panel. What I'm proposing is to make the multiple homepages option an extension of Places, so that users can select a single bookmark or a container (folder, RSS feed, etc) and use that as their homepages, and edits to the bookmark update the homepage, instead of the one-time solution we currently have. We would also display the bookmark name, instead of the URL (reuse prettyprinting code here if possible). We could still support arbitrary URLs/no home page, but the idea is that more advanced setups will build on Places and reduce duplicating URIs. Will the DnD data include the places URI so we can drag a folder? Other thoughts or bad assumptions I'm making about the nature of Places and the special URIs?
If you wanted to implement this feature, I think the best way would be to use the URI of a bookmark folder. When opening the home page, you would, if the URL starts with "place:", execute the query and open all the resulting pages in different tabs. You would probably want to be careful not to open "too many" pages in tabs. Some places queries might resolve to your entire history, which you probably don't want to open in tabs (not to mention just excessively large folders).
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 2 alpha2
13 years ago
Priority: P3 → P4
Brett, yeah, that's exactly what I was thinking. I'd bet on 15 as a absolute maxiumum (probably hidden-pref-controlled, since there's no way to determine an absolute number)
Component: Places → Tabbed Browser
Priority: P4 → P3
QA Contact: places → tabbed.browser
What I want to do here is show the bookmark/folder name, instead of the URL, when using a bookmark. Need to think about the UI for that. Depends on 331755, since that picker needs to be reimplemented...
Depends on: 331755
Whiteboard: SWAG: 2d
Target Milestone: Firefox 2 alpha2 → Firefox 3
Assignee: mconnor → nobody
Status: ASSIGNED → NEW
mconnor: are we going to fix this one, or is it time to WONTFIX?
We want to fix this, there's just a lot of fish to fry. wanted so someone can take a stab at this (maybe even me!)
Flags: wanted-firefox3.1? → wanted-firefox3.1+
Target Milestone: Firefox 3 → Firefox 3.1
This feels like it's just a way to implement bug 208182, and probably the best way, so I'm going to dupe this to it.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Target Milestone: Firefox 3.1 → Firefox 3
Duplicate of bug: 208182
You need to log in before you can comment on or make changes to this bug.