Tab Folders: About Tabs and Bookmarks

[bdbch]

Hey! This discussion is based off of this comment I made on the current tab folder PR:

#9355 (comment)

In general I think bookmarks are a way better representation of how pinned tabs should or could work. They already bring native folder support, can be synced via Firefox Sync without any issues, can be renamed and even described and the only big "problem" would be to represent them as tabs.

Imo:

• Pinned Tabs should become Bookmarks (we can still call them Pinned Tabs in the Browser as they're represented as tabs)
• Essential Tabs should become Pinned Tabs (can still be called Essential Tabs)
• When a Bookmark is closed, it should use the bookmarks data and be a stateless representation of the bookmark
• When a Bookmark is clicked / opened, it should keep the representation but hook it up to the tabs state in the background so the bookmark now represents the open tab. The bookmark is not deleted or modified in anyway (except the user tells the tab to "replace the current pinned URL")
• The Bookmark UI will then "mask" the tabs associated with them so you can still move the tab/bookmark around in the sidebar, put it in folders, etc. etc. while having a tab open

What are your thoughts? Since right now bookmarks are kinda useless in Zen this would be the perfect use case and would also help users who want to migrate back to Firefox to keep their bookmarks from Zen.

---

Since I'm a non-native speaker I tried to ask AI to come up with a good pro and contra list for both solutions. I told it to be objective and don't take a specific side:

---

1. Custom Solution (Building your own data storage & sync)

Pros:

• Complete Control: You get full control over the data structure, how "pinned tabs" and "spaces" are represented, and all associated metadata. This allows for maximum flexibility to precisely mimic Arc's unique features.
• Future-Proofing: You're not reliant on changes to Firefox's internal APIs or bookmark behavior. If Mozilla changes how bookmarks work, your custom system is unaffected (unless it's a breaking API change for the browser itself).
• Tailored Sync: You can implement a sync service (e.g., your own backend or an advanced use of storage.sync if data size permits) that's perfectly optimized for your specific data model. This could include richer conflict resolution or more frequent syncing than default bookmark sync.
• No "Pollution" of Native Bookmarks: Your "pinned tabs" won't show up in the user's regular Firefox bookmark manager, keeping the browser's native features clean.

Cons:

• Significant Development Effort: This is the most complex path. You'd need to design, implement, and maintain:
  • A custom data structure for pinned tabs and spaces.
  • All CRUD (Create, Read, Update, Delete) operations for this data.
  • A robust sync mechanism (either your own backend or very careful management of browser.storage.sync limitations).
  • Error handling for sync conflicts or data corruption.
• Sync Complexity & Limitations:
  • If you build your own backend, that's a whole new service to develop, host, and maintain.
  • browser.storage.sync has strict quota limitations (e.g., 102KB total, 8KB per item, 512 items). For extensive "pinned tab" and "space" data, this might be insufficient. You'd need to compress data or chunk it, adding complexity.
  • Firefox for Android's storage.sync doesn't currently synchronize with the user's Mozilla account, which could complicate mobile app integration for actual sync.
• Security & Privacy Considerations: If you use your own sync backend, you'd need to consider data encryption, user authentication, and privacy compliance (especially relevant in Germany/EU with GDPR).

---

2. Leveraging Firefox Bookmarks

Pros:

• "Free" Sync: This is the biggest advantage. Firefox's built-in bookmark sync (via Firefox Sync) handles all the heavy lifting of synchronizing your "pinned tab" data across devices. This drastically reduces development time and ongoing maintenance for sync.
• Reduced Development Complexity: You don't need to build a custom data storage layer. You interact with a well-defined API (browser.bookmarks) that already handles persistence, hierarchy (folders), and change events.
• Familiarity (for some users): Users familiar with managing Firefox bookmarks might intuitively understand that your "pinned tabs" are just special bookmarks, potentially simplifying adoption.
• Robustness: Firefox's bookmark system is a core, well-tested browser feature. You benefit from its stability and reliability.
• Mobile App Potential (Simplified Data Layer): If you eventually build a mobile app, it would also be able to access the same synced bookmark data via Firefox's internal APIs (though actual UI integration would still be custom).

Cons:

• Conceptual Mismatch: Pinned Tabs are about active, persistent browser state, while bookmarks are saved links. You're forcing a bookmark to act like something it's not natively, which can lead to mental friction or unexpected behavior if not handled perfectly.
• UI/UX Challenges for "Active" Tabs: As discussed, making a bookmark feel like a persistently open tab that updates in the "same context" is the hardest part. You'll need complex logic to:
  • Track which bookmark is currently open in which actual browser tab.
  • Ensure clicking a "pinned bookmark" in your sidebar activates/updates an existing tab instead of always creating a new one.
  • Potentially hide or manage the actual browser tabs opened from these "pinned bookmarks" to maintain a clean Arc-like interface, which is difficult with WebExtension APIs.
• "Pollution" of Native Bookmarks: Unless you enforce strict naming conventions (e.g., a hidden folder for your "pinned tabs"), these bookmarks will appear in the user's standard Firefox bookmark manager, which might be confusing or unwanted for some users.
• Limited Metadata: Bookmarks primarily store URL and title. If Arc-like "pinned tabs" require more complex metadata (e.g., custom icons, specific view states per space, etc.), you'd still need a secondary custom storage (storage.local or storage.sync for small amounts of extra data) to associate that with the bookmark ID.
• Dependence on Firefox API: You are entirely reliant on the browser.bookmarks API's capabilities and any future changes to it.

[bpavuk]

we don't need to rename everything to make use of bookmarks as a mechanism that underpins Essentials and Pinned Tabs

[MrModest]

Your suggestion seems to ignore the workspace scope, so I want to add on to this.

If going with the bookmark approach, then each workspace should have its own dedicated folder so its pinned tab can be living there. Otherwise, how Zen would know which workspace the just synced pinned tab belongs to.

Essential Tabs should become Pinned Tabs

I have nothing against this as well, but another note on the workspace:
Essential Tabs shouldn't belong to any workspace since they should be available across all workspaces.
As it works now in the Arc. The only nuance is, if you want a different set of essential tabs, you just set a different container for your workspace. (Arc uses different profiles for this, but in the Firefox world we have a Multi-Container approach).

I can see the bookmarks structure like this:

.
├── Zen/
│   ├── Essential Tabs/
│   │   ├── Tab1
│   │   └── Tab2
│   ├── Workspace1/
│   │   ├── Folder1
│   │   └── PinnedTab2
│   └── Workspace1/
│       ├── Folder1
│       └── PinnedTab2
└── Another Firefox root bookmark

[eXaminator]

I just want to add, that this approach ignores things like additional settings for workspaces / folders / tabs (like custom icons or colors etc.), doesn't it? So at the very least for workspaces you'll still need additional data structures (that are also part of the sync), and the same can probably be said for folders and tabs, at the very least down the line as more feature requests come in to make it more and more like Arc (or even just to because they're good ideas).

Or could bookmarks already handle all that anyways?

[bdbch]

I mean they could go a hacky route and store workspace information in the bookmarks as a bookmark itself? I think bookmark values don't need to be links/urls so you could theoretically store JSON in there.

Icons and colors are not really part of the tabs I think? except you're talking about tab groups?

[eXaminator]

1. Adding fake bookmarks would reduce the advantage that this could easily be used with non-zen firefox browsers (like mobile). One of the biggest advantages of the bookmark route for me would be that I could easily access my pinned tabs and workspaces on my phone.
2. If we compare it to arc (as may do for obvious reasons), there it's at the very least possible to change the icon, which is great especially for essential tabs. If I have 2 or 3 different pages in Jira up there that I use all the time but all of them use the same icon - that's not ideal. So that's a feature request that I'm sure will come up (at the very least by me 😁) if it's not already out there. So it makes sense to have some idea of the limits of this approach, in addition to the advantages.

[bdbch]

Adding customization per tab would probably need a custom solution. I don’t think there’s a clean or native way to do this without running into weird hacks—like storing extra data inside bookmarks, which could lead to messy titles or unusable bookmark lists.

I’m mainly thinking about this from a usability and portability angle. Since Zen doesn’t have a mobile app right now, it would be nice if customizations worked on mobile too, or could at least carry over to a Chromium-based browser if someone switches. I just prefer setups that stay flexible and don’t lock me into one specific tool or platform.

I’m not sure how bookmarks are handled internally—like whether they keep a consistent ID across sessions—but if Zen were to go with a bookmark-based approach, maybe it could store the customization data locally or sync it through its own service. Most browsers don’t support extra metadata on bookmarks anyway, so relying on that probably wouldn’t work across the board.

[eXaminator]

But that's exactly what I'm saying, you're viewing this from one specific angle, I'm trying to bring in another perspective.

I understand your view and I generally have the same view, but it's also problematic to just go with a solution without taking future developments and possibilities into consideration. I think if Zen had its own sync service a lot of this wouldn't even be an issue, besides exporting for another browser which could just be some kind of export button instead of the whole core of the workspace / pinned tab system.

So, while I think this approach would probably bring a few functions out of the box that imho are sorely missing right now (especially sync!), it might lack other features or the option to properly extend it in the future (again, I have no knowledge of this, it's just something to keep in mind). I know the dev has already made up their mind, and they might have good reasons for this. At the same time I hope they see the features that are missing (and as far as I can tell, at least sync as come up a few times) and make decisions that will lead to the implementation of these missing features sooner than later, but I also hope they take a broader perspective on this. I'm sure there will be other ways to enable sync and browser import/export. Maybe adding pinned tabs and folders (and workspaces) to bookmarks in addition to however all that is actually implemented. But that could be a separate feature and doesn't mean the whole pinned tabs feature needs to be based on bookmarks if it doesn't make sense for extensibility.

[bdbch]

Jumping in here to share some thoughts following the conversation over at this PR about the relationship between tabs and bookmarks—especially in the context of browsers like Zen and Arc.

I know there are strong opinions on both sides, and I completely understand the argument for keeping tabs and bookmarks as distinct concepts, which has been the standard in most browsers. However, I think it’s worth highlighting that browsers like Arc (and now Zen) are intentionally shifting away from the traditional model. In Arc, tabs are persistent by design—they stick around across sessions, can be organized into folders, and act almost like “pinned applications.” This persistence and organization make tabs feel less like temporary session items and more like a workspace you return to, which is why the boundary between tabs and bookmarks gets blurry for me.

Personally, I still prefer the idea of bookmarks behaving like tabs—especially when it comes to features like folders, nesting, and portability across devices and browsers. For my workflow, this approach feels more flexible and future-proof, particularly for syncing and migration scenarios.

Of course, I totally recognize that the final decision is up to the project maintainers and the overall vision for Zen. I just wanted to add my perspective for anyone else following this discussion or weighing in on the direction.

[swebber-upngo]

I whole heartedly agree with this analysis.

Anything I can do to get Zen to act like Arc will make me happy, but blurring the lines between tabs and bookmarks is a modern design idea that makes the web just feel better. Once you can organize and open and close tabs without them disappearing completely, they effectively replace any use for the traditional style of bookmarks.

There are pros and cons, but I feel the pros dramatically out-weigh the cons, and I look forward to switching from Arc to a maintained Zen browser as soon as the tab folders make this feasible.

[waLLxAck]

Pinned tabs as a bookmark replacement FAIL once you have too many bookmarks. It gets too cluttered.
Keep them separate - add an option for user to import their bookmarks as pinned tabs if they so wish.
A win-win situation.

[vraravam]

    Tabs were ephemeral and part of your session.
    Bookmarks were persistent and saved manually.

This is what I am advocating as well. and that the demarcation should continue to remain.
If I go to my bookmarks window, I DO NOT want to see a folder/section relating to my workspaces or pinned tabs, etc.

[bdbch]

I think it's important to acknowledge that the line between tabs and bookmarks has started to blur

That’s the core of what I’m pointing at here.

In Arc, pinned tabs felt much more like bookmarks that you interact with through the tab UI. They weren’t traditional tabs in the live/session sense, they were persistent, organized, and restored on demand. That blurred line is what makes this whole discussion tricky, but also kind of interesting.

What’s being proposed here (or at least discussed) is a model where pinned/workspace tabs are technically stored as bookmarks, but used and surfaced like tabs, which has a few key advantages, especially around persistence and sync. And it’s also why Arc didn’t really need “normal bookmarks” anymore: the pinned/tabbed system already fulfilled that role, just in a more integrated way.

So when you say you don’t want to see “workspace tabs” in your bookmarks, that makes total sense if you’re thinking of bookmarks the old-school way. But if we shift the mental model, then maybe those “workspace tabs” are your bookmarks, just more powerful, contextual, and workspace-aware.

One thing that actually did annoy me with Arc was exactly this: I had no clean way to access my pinned tabs or workspaces on mobile. There was no cross-device solution. If we lean into using Firefox’s native bookmark system for this, we do get that, and everything becomes accessible on any Gecko-based browser that supports Firefox Sync. That’s a pretty big win in terms of openness and portability.

Just some thoughts, I totally get the hesitation, but I think the line between these concepts is already pretty fuzzy, and maybe that’s a good thing.

[vraravam]

that makes total sense if you’re thinking of bookmarks the old-school way

I think its better to keep them separate. It doesn't matter whether its old school or not.
The point being that bookmarks are urls that I want to save for future reference, but not necessarily have them in the sidebar, etc. I constantly "bookmark" urls that I think would be useful in the future. But, if that becomes a tab, then I might end up with hundreds of "tabs" that are useless and which I have to avoid when scrolling across all tabs in a workspace.

[swebber-upngo]

No. You put them in a folder. That's the entire point of folders in the tab bar.

[bdbch]

On top of that I mentioned in my initial proposal that bookmarks that should appear on the Zen Sidebar should live in their own Bookmarks Folder so that non-sidebar bookmarks can continue to live unaffected by this.

Other example: The bookmarks bar which literally every browser has works the same way. It's putting your bookmarks explicitly added to the Bookmarks Bar in the UI element for ease of access. What would be the different to add Bookmarks living in the (lets call it Zen Sidebar) folder to show up on the Zen Sidebar as tabs.

[tealsnow]

I agree a clear decision should be made here. But these proposed changes are far too divisive. Zen has as much lineage with Arc as it does Firefox. I believe it should strive to strike a balance between the new paradigms developed by Arc and the traditional browsing experience.

Arc's approach, with its significant changes, struggled with user adoption. I believe Arc's experience highlights the challenges of introducing too many radical changes at once.
I'm concerned that forcing change and renaming elements could lead to confusion.

So I counter the proposed changes with something that hopes to strike a balance:

• Pinned tabs act as they currently do.
• Essential tabs act as they currently do, acting as a "super pinned tab" - persisting across workspaces.
• Bookmarks act mostly the same:
  • Mechanisms to convert to and from pinned tab(s) and bookmark(s) should be provided. Allowing those who wish to use the new paradigm to do so, and freely transition between the two. This should work and map one to one with folders.

While users could opt out of bookmarks, I don't believe outright removing them, even with a replacement, is the right approach.

Again, I stress: forcing change is not the way forward.

Please, if you think my proposal could do a better job, let me know. I welcome your thoughts on this proposal and am open to discussing alternative solutions.

[vraravam]

100% agree with this!

Also, at some point, if/when FF comes up with its own definition of workspaces/etc - moving to that would be technically hard AND if it were even done, then it would be a breaking change for all users who had setup their Zen browser config! Why erode the userbase with these kind of breaking experiences?

[tealsnow]

This is largely what Geezus42 proposed in this comment: #9355 (comment)

[bdbch]

I have a few problems with that argumentation. I still don't see any negatives on the bookmark approach except having to represent a bookmark into a tab when it's open & being "restricted by the bookmark feature" but I'll come back to that.

1. Zen is not Arc and is still using a lot of Firefox features for it's own feature set

I don't really see the connection why we should not use a standards just because Arc went it's own way. Pretty sure TBC actively wants to lock in their users into their browsers. Zen on the other hand is open source and is based off of Firefox which already is an extremely open system. Introducing vendor-lockins for the sake of it sucks.

2. Redundancy

Having Essential Tabs (Super-Pinned Tabs), Pinned Tabs, Tabs and on top bookmarks sounds not really well thought through. Coming from Arc for example I had a lot of things I had in bookmarks inside other browsers in my tab pinned tabs.

Lets say I want to store recipes in Private Things => Collections => Recipes and I would like to take this stuff either to mobile or other browsers what I'd need to do with your approach is duplicate my data from Pinned Tabs to my Bookmarks which causes redundancy and I'm 100% sure most people won't ever do this but just will manage their tabs instead because bookmarks and the bookmark bar are very hidden by the default Zen UI already.

3. No Zen Mobile

Having no mobile app for Zen means not having access to your pinned tabs on mobile.

Zen already has the benefit of being based on Firefox and just being able to rely on Mozilla's syncing features. Sure they can introduce their own sync server and features but that will mean they'll need to come up with a mobile browser at some point too. It's just super unnecessary to NOT use the already existing solutions just to come up with custom solutions for the sake of it.

To me it's a really powerful feature to say "Hey, we don't care you can just go back to Firefox and you'll have your History, Tabs, Bookmarks, etc. where you expect it - and if you want to come back, we'll have your Firefox things in Zen as well".

Also remember that Zen is not maintained by a company but a single person. If he stops caring or gives the project to a bad maintainer / drops it completely all that custom sync stuff will be dead while just sticking to standards would allow Zen to at least be able to life on (assuming there's someone who will at least just update Firefox in the background).

4. Going into the future

Just because we'd rely on bookmarks wouldn't mean that we lock ourselves out from future features we could build. In the end bookmarks would just be the persisted storage where we put basic tab/bookmark information. As I said in another comment I don't know if bookmarks have persistent UUIDs/identifiers, but if they have the Zen team could still just add additional metadata on their own sync servers / in the browser and add that metadata to the bookmarks extending their feature set.

---

I still stand by the point that Arc is to blame on that confusion here. If I was able to rephrase what that sidebar is I would phrase those features like that:

1. Essential Tabs => Pinned Tabs - compared to other browsers this is exactly what pinned tabs are everywhere else. Tabs pinned down into a non-closable or removable icon
2. Pinned Tabs => Bookmarks - Arc's "Pinned Tabs" are just nested bookmarks that can be turned into tabs on the fly. The visual representation is that of tabs though
3. Regular Tabs => Stay the same#

As said cheff will decide and he'll go with the pinned custom tab solution anyway. Imho it's just so much unnecessary work the team will put into making this work, feel nice, being syncable and maybe even exportable later that I think is absolutely unnecessary and I think I'll die on the hill that Arc's "pinned tabs" feature is a glorified bookmark manager.

PS: Sorry if I sound rude or something or as if I don't value your views - not meant like that. I'm just not a native english speaker and sometimes get worse and worse when writing longer texts. 😂 Genuinly just interested in finding the best & most flexible solution for Zen.

[tealsnow]

All I aim for is for everyone to have their cake and eat it too.

1. Zen is not Arc and is still using a lot of Firefox features for it's own feature set

I never claimed that Zen is or should be Arc. Only that Zen can learn from Arc's mistakes.
Nothing would stop you - or anyone else - from treating their pinned tabs as bookmarks.
Again, renaming only serves to confuse, this is evident my mere fact that Arc had to have a FAQ page explaining why there are no "bookmarks".

2. Redundancy

I hardly believe there is redundancy involved between bookmarks and pinned tabs, at least not enough to constitute removing one in favor of the other. Pinned tabs are (or will be) URLs in a tree structure, bookmarks as they exist in Firefox and Zen are a URL, name, tags and keywords in a tree structure (I have not looked at the source code, this has been gleamed from what is user facing).
I agree there is overlap, certainly not nearly enough to warrant replacement.
Both can serve different use-cases. Either could be ignored, or both could be used in conjunction, or neither could be used.

3. No Zen Mobile

This only elevates the need for bookmarks, as they exist currently, to remain. If bookmarks were to become pinned-tabs, the functionality would not translate to mobile. Thus, I say we keep bookmarks as bookmarks and pinned-tabs as pinned-tabs. With a simple method to convert between the two. Again, allowing you to have your cake and eat it too.

[...] I think I'll die on the hill that Arc's "pinned tabs" feature is a glorified bookmark manager.

I agree, and it caused confusion. There is nothing stopping Zen from making at the same while also keeping bookmarks.

Genuinly just interested in finding the best & most flexible solution for Zen.

So am I - and it is my firm believe that the best way to do that is to keep bookmarks, and not rename things unnecessarily.

---

You aim to simplify and consolidate the browsing experience. I get that, maybe you are used to how Arc does it. Many aren't. Many would like to keep their bookmarks as bookmarks and their pinned-tabs as pinned-tabs. And they should be allowed to. They should also be allowed to treat their pinned-tabs as bookmarks if they so wish - naming them something else does not change how they work.

---

Sorry if I sound rude [...] I'm just not a native english speaker

Don't worry, you don't sound rude. And your English is great, never had an issue understanding you - I've known native speakers who write far worse than you do.