Add "Open Enclosing Folder" context menu to search results of bookmarks in the Library window (link to view/open containing folder, parent folder button)

When viewing search results of bookmarks in the library window, it would be nice if we had an "open enclosing folder" contextual command when the user right clicks on a bookmark. This would navigate the Library window to that folder, and they could hit the back button on the library window to return to the search results.

Need to check on the correct terms to use on Windows, and Linux.

i suppose on Windows is "Open Containing Folder", it's like that in the file search

Mentioned just to make sure this will apply to the bookmarks sidebar as well.

"Go Parent Folder" extension (bug 196509#c68) by Alice White:
      https://addons.mozilla.org/firefox/7377
Context menu choice ("Go Parent Folder" same as name of extension) from a search result in the bookmarks sidebar will locate you to the parent folder of bookmark in normal bookmarks sidebar view.

Likewise works from right side of the Library window which appears to be always labeled/considered search results whether a user invoked a search or not.

In bug 469416 (Add "Folder" to the properties pane of bookmarks when viewing
search results), I attached a sample UI (attachment 392021 [details]) which includes the "View containing folder" button" proposed by this bug. It also includes
- "Folder column" for results table (bug 469421; SM bug 56418)

With respect to this bug, I have added the button right next to the folder widget which displays the name of the containing folder. Fits in nicely, imo.
Comments welcome. UI-review might be centralised in bug 469416, as the folder widget and button should go together.

Have a look at bug 405795, attachment 392075, where I am proposing the same UI concept for the "Add/Edit this bookmark" properties popup (yellow star), but with an *icon-size* "Open Containing Folder" button next to the folder widget.

Created attachment 392894
Windows and OS X file system

Having this as a contextual command is more externally consistent with the various file system UIs on Windows and OS X (I couldn't find a similar behavior with Nautilus in Gnome).

Directly on a folder listed in the properties pane/dialog: "Open"
On a search result: "Open bookmark location / Open Enclosing folder"

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body contains places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

This bug still has not been fixed in Firefox 3.6.4. There no way to find the found bookmark's parent folder.
Moreover, the bookmarks search is extremely slow.

Alex, I still think this idea which you filed 3 years ago would be great to have (or in fact: crucial), with an excellent cost-benefit ratio...
Would it be very difficult for you to implement this?

FTR (supporting the need for this bug):
Go Parent Folder Addon (1): 45,991 downloads; 4,707 users (this bug)
Show Parent Folder Addon (2): 42,583 downloads; 4,156 users (Bug 469421)

(1): https://addons.mozilla.org/en-US/firefox/addon/go-parent-folder/
(2): https://addons.mozilla.org/en-US/firefox/addon/show-parent-folder/

This capability should be built in Firefox, without any extension. If you find any bookmarks during search, there is no clue in which folder/subfolder they are located. The user should be able to access them upon finding them during search!

@Alex Faaborg [:faaborg]:

(In reply to Thomas D. from comment #9)
> Alex, I still think this idea which you filed 3 years ago would be great to
> have (or in fact: crucial), with an excellent cost-benefit ratio...
> Would it be very difficult for you to implement this?

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

I can reproduce this bug in Firefox 33.
As a temporary fix I use Go Parent Folder Add-on (https://addons.mozilla.org/en-US/firefox/addon/go-parent-folder/).

Firefox 52 is great. It has bookmarks.
But it is impossible to open bookmark's folder in search results.

Steps to reproduce:
1. Open Firefox
2. Open its Bookmark Manager (<Ctrl+Shift+O>)
3. Search for bookmark
4. Try to find its folder with right-click menu.
5. It is impossible to find bookmark's folder.

Expected results:
Firefox is mature, so it is expected that user can find bookmark's folder. For example Google Chrome has "Show in folder" menu option.

I reported bug to launchpad (https://bugs.launchpad.net/firefox/+bug/1672139). You may add this link to "See also".

We're at Firefox 54 and this feature is still missing.

Now, the "Go Parent Folder" has been removed by its author: https://addons.mozilla.org/en-US/firefox/addon/go-parent-folder/

So Firefox currently has no way to jump to the containing folder from a bookmark search, which is painful.

(In reply to Florian Berger from comment #16)
> So Firefox currently has no way to jump to the containing folder from a bookmark search

"Bookmarks Manager and Viewer" can do it if you are prepared to use their popup for searching and managing bookmarks.

https://addons.mozilla.org/en-US/firefox/addon/bookmarks-manager-and-viewer/

(In reply to Kestrel from comment #17)
> (In reply to Florian Berger from comment #16)
> > So Firefox currently has no way to jump to the containing folder from a bookmark search
>
> "Bookmarks Manager and Viewer" can do it if you are prepared to use their
> popup for searching and managing bookmarks.
>
> https://addons.mozilla.org/en-US/firefox/addon/bookmarks-manager-and-viewer/

Thank you very much! I added that add-on to the Free Software Directory.

(In reply to Kestrel from comment #17)
> (In reply to Florian Berger from comment #16)
> > So Firefox currently has no way to jump to the containing folder from a bookmark search
>
> "Bookmarks Manager and Viewer" can do it if you are prepared to use their
> popup for searching and managing bookmarks.
>
> https://addons.mozilla.org/en-US/firefox/addon/bookmarks-manager-and-viewer/

Bookmarks Manager and Viewer is a WebExtension!

(In reply to Norbert from comment #15)
> Firefox 52 is great. It has bookmarks.
> But it is impossible to open bookmark's folder in search results.
>
> Steps to reproduce:
> 1. Open Firefox
> 2. Open its Bookmark Manager (<Ctrl+Shift+O>)
> 3. Search for bookmark
> 4. Try to find its folder with right-click menu.
> 5. It is impossible to find bookmark's folder.
>
> Expected results:
> Firefox is mature, so it is expected that user can find bookmark's folder.
> For example Google Chrome has "Show in folder" menu option.
>
> I reported bug to launchpad
> (https://bugs.launchpad.net/firefox/+bug/1672139). You may add this link to
> "See also".

I agree that this feature should be added. I think it is best to really start demanding it in Firefox 57 since non-WebExtension add-ons won't work with it.

Created attachment 8906051
Go Parent Folder 2.9.1.1-signed.1-signed for interested users

It seems that Mozilla does not want to fix this bug in Firefox and in the SeaMonkey.
Switching to Google Chromium/Chrome is not an option.
Firefox is shipped by default on most GNU/Linux distributions. So this bug should be fixed as soon as possible.

I'm attaching latest Go Parent Folder 2.9.1.1-signed.1-signed for interested users.

(In reply to Kestrel from comment #17)
> (In reply to Florian Berger from comment #16)
> > So Firefox currently has no way to jump to the containing folder from a bookmark search
>
> "Bookmarks Manager and Viewer" can do it if you are prepared to use their
> popup for searching and managing bookmarks.
>
> https://addons.mozilla.org/en-US/firefox/addon/bookmarks-manager-and-viewer/

I don't see how that is possible with this addons.
Furthermore the performance is poor if you have 100s of bookmarks like I do

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

Actually, I believe all issues related to not having an ability to locate a bookmark's parent folder are reiterations of Firefox Bug 196509 which is now 15 years old. And if we include SeaMonkey, it's Bug 56418 is 17 years old. That said, Drew Willcoxon's Comment 86 on Bug 196509 does bring up a point about nuance differences and the request to argue them separately.

While I recognize the issue mentioned by Marco Bonardo in Comment 53 on Bug 449421 about having multiple folders with the same name, I agree that the simple functionality provided by White Alice0775's addons, "Show Parent Folder" and "Go Parent Folder", will be missed in Firefox 57+. (FYI: Here on Bugzilla White Alice0775's persona is Alice0775 White.)

For those of us who want to continue using Firefox (for me the Developer Edition) as the primary browser, please provide a some means to locate a bookmark's parent from the search results. I'd prefer two solutions. One for search results in the Bookmarks sidebar and one for search results in the Library. Ideally, for the sidebar this could be accomplished via adding a Context Menu item, "Show Parent". In the Library via a sortable column. While it would be nice if the Parent column could provide some means to toggle between column and list view (similar to MacOS's Finder dialogue window), just having the immediate parent folder would be sufficient.

A work around for the near-term -- There are a few steps. 1) Open the Bookmarks sidebar. 2) Open a tab and enter chrome://browser/content/bookmarks/bookmarksPanel.xul into the address bar & hit enter. A tree-view of your Bookmarks will appear with a search field. 3) Conduct a search query. 4) Highlight & drag all search results to a folder in the Bookmarks sidebar. 5) With that folder closed, right-click on the folder and from the Context Menu select "Sort By Name". 6) Open the folder. 7) Delete any duplicate.

The delete function can also be accomplished with any of the Bookmark management addons which have a delete / remove duplicates feature.

The 2nd step can be further simplified by using chrome://browser/content/bookmarks/bookmarksPanel.xul as your homepage.

The obvious issue with this workaround which would not be present if a Parent Column was available in the Library is when you want to keep the same bookmark in multiple places. For example, once in the Bookmark Toolbar and once in a folder in the Bookmarks Menu. A workaround for this is, of course, to use the Properties dialogue window and change the Name of one of the duplicates and then drag it back to the Bookmarks Toolbar.

While all of these steps are doable, it is substantially more work than if a means to identify a Parent Folder was available in the browser itself. Perhaps all of this isn't a Bug, but rather a FEATURE REQUEST.

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

[Tracking Requested - why for this release]:

Because Firefox 57 breaks the XUL-workaround-addon ....

Clearing tracking for 57 based on the rationale in bug 196509, comment 104.

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

anybody know another workaround?

Only other workaround that I'm aware of to find the parent folder of a bookmark from the search results is to change the browser to Offline mode (Alt > File > Work Offline) and then open up the bookmark in question. Once the bookmark is open, you can click the Star icon in the address bar to edit the bookmark and see what folder it's in.

Kind of clunky but works in a pinch :\

I sure wish this was natively built into the browser.

Thanks at least that will get me by. Clearly the browser knows which folder a bookmark is in... not sure why it's so hard to perform that process in a search result.

(In reply to Thomas D. (currently busy elsewhere) from comment #10)
> FTR (supporting the need for this bug):
> Go Parent Folder Addon (1): 45,991 downloads; 4,707 users (this bug)
> Show Parent Folder Addon (2): 42,583 downloads; 4,156 users (Bug 469421)
>
> (1): https://addons.mozilla.org/en-US/firefox/addon/go-parent-folder/
> (2): https://addons.mozilla.org/en-US/firefox/addon/show-parent-folder/

This was a great solution before. These add-ons has unfortunate not been developed into WebExtensions.

(In reply to public from comment #32)
> (In reply to Thomas D. (currently busy elsewhere) from comment #10)
> > FTR (supporting the need for this bug):
> > Go Parent Folder Addon (1): 45,991 downloads; 4,707 users (this bug)
> > Show Parent Folder Addon (2): 42,583 downloads; 4,156 users (Bug 469421)
> >
> > (1): https://addons.mozilla.org/en-US/firefox/addon/go-parent-folder/
> > (2): https://addons.mozilla.org/en-US/firefox/addon/show-parent-folder/
>
> This was a great solution before. These add-ons has unfortunate not been
> developed into WebExtensions.

In fact both add-ons has been removed from the site.

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

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

(In reply to Kestrel from comment #17)
> "Bookmarks Manager and Viewer" can do it if you are prepared to use their
> popup for searching and managing bookmarks.
>
> https://addons.mozilla.org/en-US/firefox/addon/bookmarks-manager-and-viewer/

Until things go forward in Firefox implementation, there is Bookmark Search Plus 2 add-on that can do that as a WebExtension. It build it's own bookmarks sidebar.

https://addons.mozilla.org/en-US/firefox/addon/bookmark-search-plus-2/

That web extension is great work, but because it is a web extension, we would not be able to manipulate tags.
“No management / display of bookmark tags, keywords, description field .. as Firefox does not expose those fields through its Web Extension API's.“

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

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 geos651 from comment #11)
> This capability should be built in Firefox, without any extension. If you
> find any bookmarks during search, there is no clue in which folder/subfolder
> they are located. The user should be able to access them upon finding them
> during search!

Damn after so many years no one has fixed this. This is how great browsers die. Remember Netscape?

(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.

Such "feature" of tracing the containing folder is felt by many to be an almost trivial necessity for people managing their bookmarks ...

While waiting for the solution in Firefox.. I discovered "Pale Moon" which offers this feature quite nicely ...

I don't know how to put an image in this window, hence I share this Dropbox-link for an illustration:
https://www.dropbox.com/s/iw3trcmmh44plr5/Bookmark%20Containing%20Folder%20%2B%20Patch.jpg?dl=0

(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.

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

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).

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

Is there any way to up the priority on this issue? Bookmarks in general work great; much better than Chrome, but darn it, this one item is a terribly annoying feature, i.e. not easily being able to find the folder in which a bookmark is located. Yes, I know there is a work around that sometimes works and sometimes doesn't but it sure it a nuisance to use. Anyway, great program and thank you for what you do.

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

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?

This sounds A LOT like the "Go To Parent Folder" add-on/extension for older versions of FF. That would be great if you get this to work and implemented into current FF.

If you can extend it to also work in the Bookmark sidebar, that would be a boon and truly replicate that aformentioned add-on.

(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). 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?

This sounds absolutely awesome. I wish you the best of luck and hope that getting it integrated goes well. I can't overstate how much I've been waiting for this feature.

(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)](https://wiki.mozilla.org/Modules/Desktop_Firefox#Bookmarks_.26_History) 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 ;-)

Created attachment 9233427
Bug 469441 - Added 'reveal in bookmark tree' context menu item for bookmark library searches. r=standard8,mak

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.

Created attachment 9237625
menu_proposal.png

(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?

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

I just added a bug report requesting this feature and it was assigned as a dulplicate of this bug thread. I am really glad that just this currently being discussed!
Thanks again!

(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?

Pushed by <email address hidden>:
https://hg.mozilla.org/integration/autoland/rev/f8d2fb2fe6a8
Added 'Show in Folder' context menu item for bookmark library searches and bookmarks sidebar. r=Standard8,flod

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](https://bugzilla.mozilla.org/show_bug.cgi?id=1747200) has now been resolved, so the target/selected folder will now scroll into view. Slated for version 98.

Good news. Thank you.