Isolated State of selected BSP2 tab(s)

[peter-lyons-kehl]

STORY
Thank you again aaFn for BSP2.
When searching & cross-navigating bookmarks, sometimes I look at multiple BSP2 tabs open at the same time: one pinned tab per Firefox window, two or three Firefox windows on two screens. Or, I look at BSP2 in a tab and in a sidebar.

I love how BSP2 saves & restores the open/closed (expanded/collapsed) state of the tree. Good for work continuity/focus.

But, often I'd like to "temporarily" navigate in the tree (but not just in the search results), then close such a BSP2 tab, and not have that navigation affect the saved tree state.

PROPOSAL
Have moz-extension://xxx..-...-...-...-...../sidebar/panel.html accept a HTTP GET-like "parameter" ?isolated-tree-state=true in its URL, or just ?isolated-tree-state. If present, DO load the initial expand/collapsed state of the tree, but do not store any expansion/collapse.

SCOPE and RELATED
If this sounds practical, I have a few more similar "parameters" in mind, so I'd suggest not to simplify the above, or not to change it to an anchor-like #fragment part instead.

An example of a set of such parameters could be for "local settings", overriding the standard settings, or populating the search form's magnifying glass's radio buttons without that being saved and affecting future instances/tabs, like regex=true, show=all or show=folders or show=bookmarks... And, ideally we could combine them, e.g. sidebar/panel.html?isolated-tree-state=true&show=folders.

[peter-lyons-kehl]

Another example of a "GET"-like parameter could be to override Only 1 open folder at a time : close all other open folders under same parent when opening a folder option.

Users can bookmark such moz-extension://... URLs, too. Extra benefits:

• They could put such URLs in the Bookmarks Toolbar, and then quickly open BSP2 tabs fit for a task.
• Increased accessibility for disabled people, so that they don't have to click at the magnifying glass to select the radio buttons (like Use regex).

Side note:
Thank you for commenting in BugZilla on Tags API some 6+ years ago... I'm figuring out manually created "tags" in bookmark titles. (Without renaming the "tags", which would mean changing them in all related bookmarks.) It seems promising, thanks to BSP2. If it works for me, I'll write about it.

Side note-related question: Is there any BSP2 user forum? If not,

• Have you considered enabling Discussions on BSP2 GitHub - or would that be too noisy/distracting?
• Or, could it be OK to use create BSP2 GitHub issue(s) that would not be bug/feature requests, but would be places for people to share how they use BSP2 and Firefox bookmarks (and how they suggest not to do). The benefit of such "meta" issues: Cross-referencing to other issues, or to issues in other extensions.
  Either way, thank you for BSP2.

[aaFn]

Hello @peter-kehl , interesting idea for the isolation.
As for forcing some parameters and then getting them unsaved, while the others would remain saved, this is more difficult to manage, because that would require a fine-grained control on each of them, which I do not really have in the code.

Also, I presume that this force is an "initial force" in your mind, but not preventing to change them .. correct ? (they only remain unsaved).

I need to check of course on feasibility on getting that from the URL, but I assume that this is possible at this stage, for the sake of our discussion.

So an easy proposal could be to:

• add a parameter called isolated-state (or isolated-state=true, but false doesn't mean much ..), and then all local settings would be read as you suggest, but remain unsaved.
• then enable "initially forcing" some local parameters at will .. we need to draw a list, see below.
• also, a side consequence would be that "initially forcing" any local parameter in the URL, without isolated-state, would imply an implicit isolated-state for all of them.

Fyi, here is a list of local states that are saved, and so could be isolated. Of which some could be individually initially-forced at the time of writing:

• folder open/closed state -> cannot "initially force", this would require a too complex syntax
• search panel height: search-height=ddd
• search options: search-field=xxx, search-scope=yyy, search-match=zzz, search-show=fff

=> any un-initially-forced parameter would be read from the saved state, others would be simply initially-forced but changeable, and all would be unsaved.

Let me know your views .. aaFn.