I would like this feature too, it would be useful when you search bookmarks and you wonder in what folder a bookmark is.

In a bug related to this, someone was thinking about efficiency. Does it matter if you add a button or a context menu item, then finding the path needs to be done only for that one bookmark when the user requests it. SQLite has had WITH RECURSIVE since 3.8.3, so you don't have to do recursion in code anymore.

$ time sqlite3 places.sqlite <<<"with recursive tmp(id, parent, title) as (values(0, 19006, '') union all select moz_bookmarks.id, moz_bookmarks.parent, moz_bookmarks.title from moz_bookmarks, tmp where moz_bookmarks.id=tmp.parent) select * from tmp;"
id          parent      title     
----------  ----------  ----------
0           19006                 
19006       9625        Bugs      
9625        250         Firefox De
250         168         Firefox   
168         12          Koodaus   
12          2           ATK       
2           1           menu      
1           0                     

real    0m0.004s
user    0m0.000s
sys     0m0.004s

I have 10568 bookmarks in this file.

(In reply to fluks from comment #39)

In a bug related to this, someone was thinking about efficiency. Does it matter if you add a button or a context menu item, then finding the path needs to be done only for that one bookmark when the user requests it. SQLite has had WITH RECURSIVE since 3.8.3, so you don't have to do recursion in code anymore.

Yes, it is possible to add a contextual menu to Open Enclosing Folder using WITH RECURSIVE, though opening the target folder in the Library window may not be trivial (should be feasible anyway, one has to navigate the result and open containers accordingly to the path, then select the given bookmark). It would be nicer if we'd have a quick way of extracting path for each bookmark in a performant way, but it's not strictly necessary for this specific contextual menu option. I'd be ok extending PlacesUtils.bookmarks.fetch to also fetch the path of a bookmark if a specific option is passed into it (so, on demand).
At this time we don't have the development resources to do it, so it's up to the community, if you want to contribute patches we can discuss a plan.

(In reply to Marco Bonardo [::mak] from comment #41)

I'd be ok extending PlacesUtils.bookmarks.fetch to also fetch the path of a bookmark if a specific option is passed into it (so, on demand).

Do you mean having an about:config entry?

At this time we don't have the development resources to do it, so it's up to the community, if you want to contribute patches we can discuss a plan.

I'm interested in implementing this.

(In reply to fluks from comment #42)

(In reply to Marco Bonardo [::mak] from comment #41)

I'd be ok extending PlacesUtils.bookmarks.fetch to also fetch the path of a bookmark if a specific option is passed into it (so, on demand).

Do you mean having an about:config entry?

no, a property of the options object that is passed to fetch()
I was thinking about something like let bm = await PlacesUtils.bookmarks.fetch(guid, undefined, { includePath: true }); and you'd get back a bookmark object that includes a path property, that may be something like [ {guid, title}, {guid, title}, ... ] starting from the parent up to the first meaningful root (toolbar, menu, unfiled, mobile, ...).

You could start filing a dependency bug in toolkit /Places to add that, then here you'd use that API to implement the feature in browser.

Mark Banner,

why change the status from "affected"? Maybe I not remembering what "---" means in this context.

I am on Firefox 77.

CTRL+SHIFT+O and perform a search. Hundreds of results returned that need to be grouped together better. But cannot right click on any bookmark to find where it is currently located. So how is not "affected"?

(In reply to Robert Townley from comment #46)

why change the status from "affected"? Maybe I not remembering what "---" means in this context.

"---" means we're not specifically tracking it for a particular release. This bug is open and that is enough to record that it is still an issue. It is not currently a priority for us as there are many other things that we are working on (See also comment 41).

I've got some working code that I was going to submit to Phabricator, but I thought that I would check here first on the protocol for context menu changes. I opted for a "Reveal in Bookmark Tree" context menu entry in the Library that would navigate to the appropriate place in the tree and then highlight the entry in the right-hand panel (this seemed more sensible than devising a new window just to show path). Is there some specific vetting process for menu/GUI changes? Are there other reviewers other than Mark or Marco that need to be included in the commits?

(In reply to Lebar from comment #51)

I've got some working code that I was going to submit to Phabricator, but I thought that I would check here first on the protocol for context menu changes. I opted for a "Reveal in Bookmark Tree" context menu entry in the Library that would navigate to the appropriate place in the tree and then highlight the entry in the right-hand panel (this seemed more sensible than devising a new window just to show path).

Hi Lebar, thank you for working on this, that's awesome! The behaviour sounds good to me (but it's not my call).

The reporter of this bug, Alex Faaborg [:faaborg] (Firefox UX) has provided some UX feedback in comment 6. Reveal in Bookmark Tree sounds exciting (as in 'Rise the curtain on this bookmark!'), but probably plain vanilla Open Containing Folder will be best for Windows (perhaps with variations like Open Enclosing Folder for other operating systems, but don't worry about that now). FF also uses Open Containing Folder for downloads when you hover the folder icon.

Is there some specific vetting process for menu/GUI changes? Are there other reviewers other than Mark or Marco that need to be included in the commits?

Looking at the official owners and peers of the Bookmark and History (Places) module, Mark or Marco should be the right people to review this.
Just file your patch on phabricator first (make sure to link it to this bug by filling the bug number in the appropriate field) and set Mark as a reviewer. He will certainly advise you on the next steps.

I work for Thunderbird, but I'd love to see this fixed as you can see from my comments here from time immemorial ;-)

Hi Mark,
As per flod, in response to D121040, perhaps you could point me in the right direction for getting the correct term to use in the UI (and the code for that matter) for this feature. Since the original suggestion was quite some time ago (~12 years), and it seems like "reveal" may not be the ideal term (as used in things like "Reveal in Explorer" or "Reveal in Finder"). Thanks.

I am so glad to hear this is now being worked. Thank you.

As for a name, how about the term Chrome uses when you right click a URL bookmark in your library, which is "Show in Folder." I am not sure how you wish to implement, but if you just open Chrome I think it does it well. I'm not as happy with their bookmarks mgr as with the FFox Library, but the "show in folder" feature works nicely. When you click it, you just move to the folder containing the bookmark in question. The folder is highlighted in the folder tree and all bookmarks in the highlighted folder, including the one you are interested in, are shown. Check it out. I would vote for that for Ffox.

Alternative names:

• Reveal in Bookmarks
• Show Parent Folder

Again, having this work not only in the Library window but also the Bookmarks sidebar would be a boon.

(In reply to eberger from comment #57)

I am so glad to hear this is now being worked. Thank you.

As for a name, how about the term Chrome uses when you right click a URL bookmark in your library, which is "Show in Folder." I am not sure how you wish to implement, but if you just open Chrome I think it does it well. I'm not as happy with their bookmarks mgr as with the FFox Library, but the "show in folder" feature works nicely. When you click it, you just move to the folder containing the bookmark in question. The folder is highlighted in the folder tree and all bookmarks in the highlighted folder, including the one you are interested in, are shown. Check it out. I would vote for that for Ffox.

I want to make sure that's clear to avoid unintended side effects (like making the user open the folder themselves). The intended functionality is that when the button is clicked, the bookmarks library/sidebar/etc opens the containing folder on its own and scrolls down (well, it doesn't actually do any visible scrolling, but opens to the position in that folder where the bookmark is) to the bookmark that the user clicked "Show in Folder" on. As well as opening the folder to where the bookmark is, the manager also highlights the folder location in the list of folders/folder tree (which AFAIK it does when you open a folder the normal way, so it's probably the same code for that).

Basically, it just programmatically opens the folder and then locates the bookmark.

(In reply to Lebar from comment #56)

Hi Mark,
As per flod, in response to D121040, perhaps you could point me in the right direction for getting the correct term to use in the UI (and the code for that matter) for this feature. Since the original suggestion was quite some time ago (~12 years), and it seems like "reveal" may not be the ideal term (as used in things like "Reveal in Explorer" or "Reveal in Finder"). Thanks.

Thank you for working on this, it is good to see this moving forward. I've asked our user experience team to take a look, so I'm passing the NI over to them.

Romain, can you review and help prioritize this? Thank you.

Adding needinfo to Romain as I think that was missed. Note: this is a patch from a contributor for a long standing paper-cut issue, and we mainly just need help with an appropriate string.

(In reply to Mark Banner (:standard8) from comment #62)

Adding needinfo to Romain as I think that was missed. Note: this is a patch from a contributor for a long standing paper-cut issue, and we mainly just need help with an appropriate string.

Thanks for the ping, first I want to make sure that I correctly understand the change, my understanding is:
1 Open the library modal
2 Enter a search term in the "Search bookmarks" search bar, results appear
3 Right click one of the search results, context menu appears. One new entry "Open Containing Folder" is available underneath the other "Open" entries
4 Selecting "Open Containing Folder" opens the bookmark folder and selects it on the left hand side and selects the bookmark on the right hand side

Assuming the above is right I'd propose the following:

• use "Open Containing Folder" for consistency with the "Downloads" section of the "Library" Window where this context menu entry already exists
• Locate this new entry underneath other "Open" entries

(In reply to Romain Testard [:RT] from comment #63)

Thanks for the ping, first I want to make sure that I correctly understand the change, my understanding is:
1 Open the library modal
2 Enter a search term in the "Search bookmarks" search bar, results appear
3 Right click one of the search results, context menu appears. One new entry "Open Containing Folder" is available underneath the other "Open" entries
4 Selecting "Open Containing Folder" opens the bookmark folder and selects it on the left hand side and selects the bookmark on the right hand side

Yes, that's the intention and what the patch currently does.

Assuming the above is right I'd propose the following:

• use "Open Containing Folder" for consistency with the "Downloads" section of the "Library" Window where this context menu entry already exists
• Locate this new entry underneath other "Open" entries

That sounds good to me. One slight different to Downloads is on Mac we'll want to keep "Open Containing Folder" and not use "Show in Finder" (obviously).

Lebar, please could you update the patch for that?

Meridel, can you please confirm if you're OK with the suggested change on Comment 63?

(In reply to Mark Banner (:standard8) from comment #64)

(In reply to Romain Testard [:RT] from comment #63)

That sounds good to me. One slight different to Downloads is on Mac we'll want to keep "Open Containing Folder" and not use "Show in Finder" (obviously).

Lebar, please could you update the patch for that?

Yes, I should be able to update the patch next week. Thanks Mark and Romain for looking into this and providing the updated info.

"Open containing folder" is a bit confusing. I'd recommend this label, which could be used in both instances that Romain describes (context menu from search results, and context menu for downloads): Open folder

Romain, agree?

I disagree. "Open containing folder" is common terminology and makes it clear that you are opening the folder that contains the bookmark you are examining. This is how Chrome does it. I also use a fabulous file manager called Directory Opus that uses the same terminology.

I concur. Open Containing folder is extremely common usage across all sorts of programs (esp. web browsers, but also most file managers - can confirm with Nautilus as well) and is even used by Firefox's download manager. Keeping this consistent is a must.

We met with Meridel, I agree with her that "Open containing folder" may make sense to the technical audience but will feel clunky / not plain language for general population.
Chrome and Edge use "Show In folder" which feels more natural and will align with other browser patterns.
We decided to go with "Show In folder" for this reason and I also raised bug 1729447 to address the download panel context menu for consistency.
I hope everyone feels this is a good approach, never easy to find the right labels given the variety of user types.

This has been a long-standing issue and I am pleased to see it is now actively being work. Can someone suggest when this might be complete and what version of Firefox might contain this useful change?

https://hg.mozilla.org/mozilla-central/rev/f8d2fb2fe6a8

That's exciting. Thank you. Since v93 just installed on my PC today, hopefully v95 is not too far in the future.

Thank you for adding this very useful function!

Also thanks from me! This is everything I've ever wanted. :D

Likewise, my gratitude for this simple and useful feature. Now if only someone could make a pdf viewer that would print pdfs as well as does Edge, without losing lines and the bottom of the page and other features, I would be totally happy with Firefox. I will post this as a separate bug.

@rcanderes "This is everything I've ever wanted." Really? Ok.

That said, thanks for implementing this. Very nice to see this.

One minor fix would to the implementation: would it be possible to bring into focus the location in the bookmark list? At present, the result can be far below and out of sight if the result is in a folder with lots of bookmarks, requiring to scroll to find it.

(In reply to smayer97 from comment #80)

One minor fix would to the implementation: would it be possible to bring into focus the location in the bookmark list? At present, the result can be far below and out of sight if the result is in a folder with lots of bookmarks, requiring to scroll to find it.

Yes, it sounds like a valid improvement, I was sort-of expecting that to work already, you should file it as an enhancement bug.

Done, here: https://bugzilla.mozilla.org/show_bug.cgi?id=1747200

Agreed. It seems that neither selectLeftPaneContainerByHierarchy nor selectItems actually scroll the view.

@rcandres and @eberger and others, I'm glad that I'm not the only one that uses bookmarks extensively and wanted show in folder functionality ;-)

BTW Bug 1747200 has now been resolved, so the target/selected folder will now scroll into view. Slated for version 98.

Good news. Thank you.