<tree id="bookmarks"> in selectBookmark.xul is used to select a bookmark to use as the home page. A folder can also be selected to open all the pages inside it when the browser starts. The folder selection feature may actually be obsolete, because this functionality is now provided by pinned tabs. If we want to preserve it, though, there may be other ways to make a choice. Also, selecting a bookmark to use as the home page may be done by opening the bookmark first and then using the current page. Another way is the autocompletion feature in the input field, although this may also be removed at some point.

As noted in bug 1429142, Aaron may have thoughts.

(In reply to :Paolo Amadini from comment #0) > The folder selection feature may actually be obsolete, because this > functionality is now provided by pinned tabs. Marco, while waiting on thoughts from Aaron, what do you think of removing the ability to specify a Bookmarks folder as a home page? This uses a special Places folder syntax, and I'm wondering if this is the only consumer and would help with simplifying the Places code. In general, it seems to me this feature would be rarely used, and at the moment we can still have multiple home pages specified individually. Also, we already have add-ons APIs that might easily emulate this functionality, opening multiple tabs.

(In reply to :Paolo Amadini from comment #2) > This uses a > special Places folder syntax, and I'm wondering if this is the only consumer > and would help with simplifying the Places code. No, it wouldn't help simplifying Places, afaict, this uses the same code as most of the other Places trees around, it's just the bookmarks root, we use the same in the Library, the Sidebar and the Star panel. > In general, it seems to me this feature would be rarely used, and at the > moment we can still have multiple home pages specified individually. Also, > we already have add-ons APIs that might easily emulate this functionality, > opening multiple tabs. I honestly don't have enough data to make a call, because I doubt we have any numbers of how many users depend on this. My gut feeling is that it's a low number, but it's just a guess. There are alternatives, true, whether those alternatives are sufficient is more of an UX question. Personally I'd not have anything against the removal, but the code benefit is low since we have the same tree in many other secondary UIs, the downside is pretty much unknown, since we don't have usage numbers. This question is really more pertinent to UX and UR.

Cool, thanks for the feedback! So, while there is clear benefit in removing the selector so we won't need to rewrite it without <tree>, there is no big cost in keeping the core feature, which can still be used by existing users who have already selected a folder or who want to build a folder URL manually.

oh wait, it looks like we may have telemetry: Services.telemetry.scalarAdd("preferences.use_bookmark", 1); https://searchfox.org/mozilla-central/rev/3fdc491e118c5cdfbaf6e2d52f3466d2b27ad1de/browser/components/preferences/in-content/home.js#350

This tells us how many people click on the button, regardless of whether they chose a bookmark or not, or changed their mind later. Also, do we have any denominator to which we can compare the value? I don't know how to access the scalar data.

Heh, the scalar data is not available on current dashboard because it expired. it's available as historical data, but it's not trivial to look at it (need to use Spark or a longitudinal query on old data, but I wasn't lucky trying to query it).