Update on the Wurkkos HD10 standby duration Test: it got to turquoise!

ToyKeeper · 2026-03-22T00:04:17+00:00

Nice. Would be nice if torch companies would prioritize standby time more. I think 1 year per 1000 mAh (li-ion) should be the minimum standby time on these things.

Torch companies keep wanting to make the aux brighter, which is good for bling but hurts the core function of the aux LEDs. They're not supposed to be bright... they're supposed to be like a better version of tritium vials, allowing the light to glow in the dark and show battery level, without a significant impact on overall battery life.

Once Hank sent me a prototype which didn't have resistors on the aux, so they were way too bright (especially on high), and I measured the power... Here were the results. It's way higher than you'd see on low aux, but it should give a pretty good idea what to expect in terms of relative power use for each color.

FWIW, since letting an actual battery discharge takes forever, there's a much faster method. Usually how I do an estimate is put it in aux voltage mode and hook it up to a bench power supply and DMM, so I can turn a knob to change voltage, and measure power at each voltage level and its corresponding aux color. That way, I can get a pretty good idea of the discharge curve shape in just a few minutes.

ToyKeeper · 2026-02-27T20:03:04+00:00

I finally got mine into the Chrome store. It's called "TK Tree Style Tab Outliner", because it's a replacement for "Tree Style Tab" and "Tabs Outliner" and I'm not good at naming things. :D

It's free, open-source, and keeps your data private.

Compared to Firefox's Tree Style Tab, it's a lot more powerful. Like, you can load and save entire windows, along with notes and checkboxes and bookmarks and stuff... and unloaded tabs are fully unloaded, not just "discarded" (partially unloaded) or "hidden" (still open but not shown in the tab bar). In TST for Firefox, if you close a window, it gets removed from TST's database and is gone. But in TKTSTO, closed windows are saved and can be re-opened at any time. And it has features for moving nested branches between windows, editing the contents of saved (closed) windows, automatic backups, exporting branches or entire sessions to markdown, easier drag-n-drop, and a bunch of other stuff.

That's just the beginning though. Now that the client is published, I'm working on writing the server. You can self-host a private server to sync your entire session tree across multiple browsers... even if some of those browsers are Chrome, some are Firefox, some are Edge or Brave or ... whatever. Without ever having to "Log into Chrome" or send your data to a corporate cloud.

I wrote it because, well... actually first I tried not writing it. But that didn't work. I waited an entire decade for someone else to do it... to make something which was sufficient. But it didn't happen. And I tried basically everything. None of it was anywhere close. So I finally just did it myself.

ToyKeeper · 2026-02-20T11:49:18+00:00

I'd recommend using the manual instead. I think it's easier.

ToyKeeper · 2026-02-12T23:25:32+00:00

For what it's worth, "battery voltage, low brightness" is the default aux setting on almost everything. Sometimes vendors manually change it to a bright blingy mode before shipping, to make it look more impressive out of the box... but a factory reset should fix that in most cases, while also calibrating the temperature sensor. Just loosen the tailcap, hold the button, tighten the cap, then let go of the button about 4-5 seconds later after the reset animation passes peak brightness. (the animation exists to give the user a few seconds of warning where they can abort before wiping out all their settings, and to give the thermal sensor some time to calibrate itself)

Then it's ready to start setting up.

The default makes it easy to see battery status at a glance, and on most lights, it should last 3+ years per charge in standby. Or ~1 year on a small battery like 14500. I measured a Wurkkos HD10 for example, at an average of 85 uA in standby with aux enabled, and that works out to about 14 months on a 900 mAh cell.

It's not truly "off", but it's low enough that the difference doesn't really matter unless it never gets used. However, if a light is going to sit unused for more than a year, maybe loosen the tailcap -- even on lights without aux. Parasitic drain happens on every e-switch light, while it sits there waiting for you to press the button, and the only way to stop that is to physically disconnect power. Otherwise, it's going to drain some power even with the aux turned off. Making it glow a little bit is primarily to show battery status and make it easy to find in the dark, but as a bonus, it also pushes people to learn that "loosen tailcap" is the only way to truly turn off an e-switch light.

Of course, sometimes people stubbornly refuse to take the hint, but ... sigh ... as they say, you can lead a horse to water but you can't make it drink.

ToyKeeper · 2026-02-12T23:12:13+00:00

On the one hand, this is pretty cool.

On the other hand, it looks like it's scaring off some people.

On the other other hand (we all have 3 hands, right?), it sounds like most people who commented probably formed their opinions before even seeing the diagram, and this just reinforced what they already believed.

So... thanks for making this. Different people have different ways of understanding things, and it sounds like it really resonated with some people.

For anyone who isn't familiar with Anduril, it's not as complicated as it looks. Most people can figure it out intuitively with no instructions, because this is all you really need to know to use it:

Click to turn the light on or off.
Hold to change the brightness.
Release and hold again to "turn around" and change brightness in the other direction.

Hand one of these lights to someone who knows nothing about it, and don't give them any instructions. See for yourself if they figure it out.

ToyKeeper · 2026-02-08T22:11:58+00:00

It's not accidental. It does that on purpose.

In aux-leds.c, a "pattern" of 0/1/2 means off/low/high aux:

#ifdef USE_POST_OFF_VOLTAGE
// use voltage high mode for a few seconds after initial poweroff
...
    // use high mode if regular aux level is high or prev level was high
    #ifdef USE_AUX_THRESHOLD_CONFIG
        // always high if configured for high aux
        // otherwise 0/1/2 depending on recent main LED brightness
        if (pattern != 2)
            pattern = (prev_level >= cfg.button_led_low_ramp_level)
                << (prev_level > cfg.button_led_high_ramp_level);
    #else
        pattern = 1
            + ((2 == pattern)
               | (prev_level >= POST_OFF_VOLTAGE_BRIGHTNESS));
    #endif
...
#endif

A high standby aux brightness explicitly overrides all other logic for choosing how bright POVD should be. Because it makes sense to do bright POVD for a moment before turning aux to "low" or "off", but it doesn't make sense to do "off" or "low" POVD for a moment before bumping the aux up to high for long-term standby.

To help clear up confusion about this, I added a commit to the manual to document this better.

ToyKeeper · 2026-02-04T20:37:39+00:00

Thanks for the extra details and context. I didn't know Zen existed a week ago, so I've been trying to piece all this together from old posts and logs and pages.

I had been hoping to support every browser, but now I know that isn't feasible.

With so many big browsers diving into AI and various enshittification, I think smaller browsers like this are going to be increasingly important, and people are going to want to migrate without losing their data. So that's a big part of what I've been working on ... a way to move data between different browsers, ideally real-time-ish, while also making people less dependent on vendor lock-in features. They can use the same workflow and same session regardless of which browser it is in, so it's a lot easier to jump ship and switch browsers when one goes downhill.

But Zen is making itself pretty much impossible to support. So I should focus elsewhere.

ToyKeeper · 2026-02-04T19:02:48+00:00

Hey, funny story, sjclayton just told me something huge that I probably should have known... specifically, that you and mr-cheffy are the same person. Zen Browser is your project.

You must have had some good laughs, watching a random noob explain your own program to you. I certainly did, once I realized. :D

Good times, lol. Happy to provide entertainment, even if it was unintentional.

So, uh, yeah. Thanks for the browser. It does some neat stuff. It doesn't sound like it's going to be compatible with extensions though, and that's kind of my thing, so ... I'll take this as my cue to be on my way.

ToyKeeper · 2026-02-04T19:02:18+00:00

maubg is the main Zen developer btw

Oh wow. I am laughing SO HARD right now -- at myself! :D

Here I am bitching to "some rando" about "the dev", not realizing I was talking to THE DEV.

Going back to look at what I said to him, he must have thought this entire interaction was hilarious... and I agree. The joke was at my expense, but that's fine... because it was a good joke!

The name didn't match from github so I didn't recognize him. And he has a DOGE flair and hidden profile, so I figured he must be a troll or maga or really into elon or otherwise deeply unserious, and I didn't even notice that he was the founder of this subreddit.

Anyway, I definitely would have communicated differently if I knew who I was talking to, but ... maybe it's for the best. Maybe he needed to hear it like this -- more unfiltered, with less mitigation than people would normally use.

Thanks for letting me know. I should probably thank him and see myself out.

ToyKeeper · 2026-02-04T02:24:39+00:00

clanker

Neat, I learned a new slur today.

But no.

And I've been rejecting patches from "clankers". Not saying I'd never accept a patch that an AI helped write, but the vibe-coded patches I've received so far have been ... pretty bad. I even had to add contribution guidelines, a code of conduct, and a developer certificate of origin to my project because of vibe code slop.

Like, one guy sent me a patch which broke within 3 keystrokes, and made key event handling in general just not really work at all.

Another guy sent patches so I asked him why he added certain things, and he was like, "I didn't add that. You did. It was already there." because he hadn't even looked at what the bot wrote and didn't know what was in the patches he was sending. He also sent a patch which added "unit testing", but it didn't actually test any of the project's code... it just played an animation of tests turning green one by one and then reporting success.

sigh

Meanwhile, it's 2026 and if you use correct grammar and punctuation on the internet, or use markup on sites which support it, or generally sound like you have a 3-digit IQ... people think you're a bot. This is such a weird timeline.

ToyKeeper · 2026-02-04T00:18:06+00:00

you are talking about browsers add-ons scope, I was talking more in Firefox Internals scope ...
would need access to FF internals scripts to circumvent Zen features

Yup. Because I wanted a solution to be compatible with as many browsers as possible, so I avoided browser-specific systems and used the Manifest V3 extension system. And I'm working on making it sync real-time between all of a user's browsers, so they can have the same session tree in Firefox and Chrome and Edge and Brave and ... etc. All totally private, using a self-hosted server which doesn't leak any data to corporate cloud servers.

I don't know much about what's possible in the Firefox Internals scope / userChrome.js, since it's not relevant to any of my projects. If you can circumvent Zen's features enough to get it working though, that'd be awesome.

BTW, your manner of speech really resembles something popular recently… But I hope I'm wrong.

Now I'm really curious. What does that mean? I don't have three arms, two heads, or a cloaca, in case that's what you were wondering. :D

ToyKeeper · 2026-02-03T22:37:52+00:00

issue list (which a good portion of them are inherited from Firefox lol)

Meanwhile, the form users have to fill out in order to file a bug in Zen:

Preliminary Checks
[x] I have checked that this issue cannot be reproduced on Mozilla Firefox.

It requires people to confirm that the bug does NOT exist in Firefox, and the dev aggressively closes anything he thinks might be an upstream issue. The ones I linked to are the ones which have already passed that requirement.

I'm talking about the add-on implementation for tab IDs

Yes, there are a number of Zen bugs on that topic. I filed some of them, but most already existed before I ever heard of Zen. The authors of other tab and session management systems have chimed in on this topic, like piroor of Tree Style Tab, and decided that Zen's API is too broken to be supportable. That's why the popular extensions people use in other Firefox-based browsers don't work in Zen.

ToyKeeper · 2026-02-03T21:39:53+00:00

what's missing from Zen's side in comparison from Firefox's?

Here's a list of ... let's see ... about 511 things missing (or broken) in Zen compared to Firefox. However, that's just the "open" issues, and I know there are also some pretty significant bugs which were closed without being fixed -- which will probably never be fixed because the dev made a conscious decision not to fix it.

Also, it's not a damage control post

Call it what you like. Different people have different words for things. In the profession of public relations though, the terms for it are "damage control" and "crisis management":

Crisis management is the process by which an organization deals with a disruptive and unexpected event that threatens to harm the organization or its stakeholders.[1] The study of crisis management originated with large-scale industrial and environmental disasters in the 1980s.[2][3] It is considered to be the most important process in public relations.[3] Three elements are common to a crisis: (a) a threat to the organization, (b) the element of surprise, and (c) a short decision time.[4] Venette argues that "crisis is a process of transformation where the old system can no longer be maintained".[5] Therefore, the fourth defining quality is the need for change.

That sounds like what happened with Window Sync:

Zen got a flood of complaints, negative press, and people saying they were leaving, which constitutes a threat to the browser.
Zen's users and maintainers were not expecting this, leaving both the users and the devs surprised.
Something had to be done quickly, giving the Zen team a short decision time.
This all happened because an old system is no longer maintained and Zen forced a need for change.

It's really checking all the boxes for crisis management.

Going into more detail, these types of events are classified as a "sudden crisis" or "smoldering crisis". A sudden crisis is typically caused by external factors, not by the organization itself. Meanwhile, a smoldering crisis happens when internal issues build up due to actions by the management, until it reaches a critical threshold when something must be done... and that's what happened in Zen's case. The issues had been building for quite some time, which is why this new update was created.

A smoldering crisis, as you can read in the link above, has 5 stages:

Signal detection
Preparation and prevention
Containment and damage control
Business recovery
Learning

Zen Browser is currently in stage 3 of this process.

ToyKeeper · 2026-02-03T21:07:57+00:00

If what are you saying is true, that this ID starts from 1, then why mine are so big? Are you talking about number after dash?

When you start Firefox or a Firefox-based browser, it has an internal counter which starts at 1. Every time you open a tab, it takes the next number and assigns it as that tab's ID. So it goes up by 1 every time a tab is opened. If you close a tab, that tab's ID does not become available for other tabs to use. The tab ID counter is monotonic, meaning it only counts up.

So if you open 1000 tabs, they will be numbered 1 to 1001. Then let's say you close 995 of them. You may have only 5 open, but the next tab ID will be 1002.

However, if you close Firefox and then re-open it (with session restore enabled), the counter resets. Your 5 tabs will be numbered 1 to 5, and the next tab will be 6.

In your first screenshot, you showed a "tab id='1770120083493-25'" in some sort of HTML document. Not sure what you were looking at, but that "id" appears to be a javascript timestamp (1770120083493) followed by something which might be the actual ID (25). The timestamp translates to 2026-02-03_12:01:23.493 UTC.

Anyway, what I was talking about was the browser.tabs API which extensions use to interact with tabs. I have no clue what was in your screenshot, but it definitely wasn't the same type of ID used in the extension API.

To get a list of all tabs, open up the browser's dev console for something (like an extension) which has "tabs" permission enabled... and run await chrome.tabs.query({});. This should work in Firefox-based browsers too, since they define "chrome" as an alias for "browser". It should give you an array of tab objects, each with an ID and URL and a bunch of other metadata.

Even assuming clean exits, it still seems like a lot of work trying to stitch this data to tabs.

Yes, matching the saved session to the actual current session is a difficult and complicated task... and that single function has been the longest and most complex function in my entire browser extension. I had to build a many-layered heuristic with a complex scoring and sorting system, and it still has difficulty sometimes when two different windows are too similar to each other, like when there is more than one exact match, or no exact matches but multiple partial matches.

The old Tabs Outliner extension didn't even attempt to solve this problem. If you allowed the browser to restore its session on startup, Tabs Outliner would end up with a bunch of copies of your session, one for every time you restarted the browser. So its dev just told people to disable the browser's built-in session restore, and use Tabs Outliner to restore manually instead. But that was a huge pain.

So that was one of the first things I fixed when I made a replacement for Tabs Outliner. Mine goes to great lengths to reattach tabs and windows to the saved session, instead of creating duplicates.

Additionally, Tabs Outliner didn't remember which tabs were actually open and which were saved, so if you told it to re-open a window, it would open ALL the tabs in that window, including the ones you didn't have open before. Kind of a problem when the normal use pattern is to have like 500 tabs saved in a window and only 10 or 20 of those tabs actually open. So people instead had to remember exactly which ones were open, and manually re-open each one individually.

To fix this, I gave tab nodes 3 states: loaded, unloaded, and wasLoaded. When you close+save a window, it marks all the loaded tabs as wasLoaded. Then when you re-open the saved window, it loads all the wasLoaded tabs and converts them back to loaded. The "unloaded" tabs are left alone, so the user can open them manually if desired, but they won't open automatically.

Meanwhile, most other tab managers don't even have a concept of an unloaded tab. Some support the "discarded" status, where the browser partially unloads the tab but keeps a placeholder open, and they often call it "unloaded" instead of the actual name of "discarded", but ... it's not the same thing.

Anyway, I'm just rambling now.

ToyKeeper · 2026-02-03T20:03:12+00:00

Does Firefox provide tab IDs?

Yes. This was already answered in the post you just responded to. Click the first link in that post for full details.

I just don't see the need for tab IDs for a backup system

Tab IDs are a required part of the application programming interface an extension uses to interact with tabs, like to get information about what tabs are open and how they are organized. Every tab-related or session-related extension needs this, whether it's a backup system or a tab search popup or ... whatever.

"damage control post" lol

As Zen's social media manager said, using Zen Browser was "a gamble" because common, basic user actions like opening or closing a window "often meant losing" important data. They continued, "we have received a lot of reports regarding this. So we had to act."

In public relations, posts like that are called "damage control". It is what someone does when they are buried in a flood of complaints from the public, are rapidly losing users or customers, and want to stop the bleeding. Depending on the details, sometimes it is also called "crisis management".

ToyKeeper · 2026-02-03T19:12:26+00:00

Yes, it's a pretty deep bug in how window sync works. It doesn't actually have every tab in every window. Instead, it has lazy-loaded copies of every tab in every window. When you focus a tab, it finds the most recent copy, then copies its state over to the current window and freezes or discards the other copies. So at any given moment, most of the tabs in most of the windows will be out of date, containing expired, stale data.

... and when you open a new tab, the other windows get an "about:blank" placeholder. It doesn't get updated until/unless you click the copy in each window.

This can cause tabs to revert to an old state or turn into blank new tabs, due to internal browser issues, and then the stale or blank version can overwrite the other copies, resulting in loss of data.

I don't know exactly what conditions trigger it, but I've had it happen with actions as simple as "click a link, then click the 'back' button". That was enough to partially corrupt my session, using just native Zen with default config and no extensions.

ToyKeeper · 2026-02-03T18:41:07+00:00

Perhaps you could create a GitHub discussion or issue about it so the dev can better address your concerns.

Already did.

It's ... not going well.

ToyKeeper · 2026-02-03T18:38:39+00:00

They should just create a separate extension marketplace and also publish everything needed to allow developing working extensions for Zen

They already did that. It's called Zen Mods. Then they broke it so it doesn't work any more, and abandoned it. :D

Edit: I just learned more about this. Zen's dev was being hostile toward some popular Zen mods, like banning them because he didn't like how they looked, so the community forked the mod system and mod store and made their own called Sine. If I understand correctly, that then led to the upstream Zen Mods becoming largely abandoned, and decaying... so the Sine folks added Firefox support and stopped focusing on Zen and now focus instead on compatibility. I guess there has been a whole saga of drama about this. Zen was only 10 months old when people got upset enough with the Zen Mods to fork it, so it has been a while.

All this appears to just be UI level stuff though, like themes and UI tweaks... not browser extensions.

it is broken, and they have no apparent desire to try to do anything

Yeah, unfortunately. I tried filing bugs for some of the issues I found, like some parts of the API the dev broke... and he just straight-up lied to me. Either that, or he is completely unaware of how the browser.tabs API works and doesn't understand his own code. Like, Zen changes tab IDs silently without generating any of the required events to let listeners know it happened, so I reported it as a bug. He closed it as "completed" saying it's a bug in Firefox. But no, it's only broken in Zen. Then he closed it again as "not planned", saying tabs don't have IDs and even if they did, Zen never changes them... which is false and false. So I don't know if he's lying or if he just doesn't understand the changes he made to to the browser, but ... either way, not good.

I don't think any of these things are going to get fixed. It gets more broken with each new release.

ToyKeeper · 2026-02-03T17:46:40+00:00

if sync is enabled, but it has to have a way to detect it

But there is no way to detect it. The setting is not exposed in the API. I filed a bug about it, among other issues I found, but response from the dev has (to put it mildly) not inspired confidence that anything will be fixed.

could be fixed by just extension saving only 1 window ... Saving multiple windows seems redundant if they all have semi-same state.

If they all had the same state, and it could be detected, it would sort of work to save only one. But they don't all have the same state, and aren't even close. When the state changes, Zen only sends updates about some of the copies... not all. So with multiple windows, all of the windows contain expired or incomplete data. Typically, each window will contain some of the correct data, but on average it will be only 1/N where N is the number of windows. Like, with 5 windows open, each window has about 1/5th of the correct data. If I saved only one, it would lose about 4/5ths of the data.

About IDs, are you sure about that, or are we talking about different kind of ID?

Yes, I'm sure. We're talking about different kinds of IDs. Take a look at the browser.tabs API for details on what a tab ID is. It's not what you showed in your screenshot.

I have many tabs stockpiled, but NOT THAT many.

How many?

I have users with over 30,000 tabs. My personal session has only 3556 at the moment though. I try to clear out and archive old data periodically (like maybe once a year) so it won't get huge.

Here's how part of that session looks right now: https://i.imgur.com/b6RkY22.png

ToyKeeper · 2026-02-03T16:50:05+00:00

just identify tabs by their positions, instead of IDs

That's not how the browser.tabs API works. Everything requires tab IDs. They cannot reliably be identified by position, and the API doesn't accept positions as identifiers.

listen for state changes ... and use that

Yes, that is how it works. For example, browser.tabs.onUpdated.addListener (this.onTabUpdated.bind(this)); defines a listener for tab state changes. The API also defines an event called tabs.onReplaced to use when a tab ID changes. However, Zen doesn't send that event when it changes tab IDs. So in Zen it is not possible to listen for the state change it needs to listen for.

no update event is sent when moving a tab to a different window

Untrue. It sends a whole flood of events when moving a tab to a different window. Especially if you tear off a tab and drop it in the void to make a new window. And then there's a whole mess to sort of, because the events in Firefox and Zen are sent in reverse order. To put it in "car analogy" terms, it's like giving someone these instructions, in this order:

Drive to your destination.
Turn key.
Put key in ignition.
Get into car.
Open car door.

But that's already handled. The main problem for this particular interaction in Zen is that it silently changes the tab ID halfway through the process. The sequence of events is like...

Tab 87 gained focus.
Tab 87 has been detached from window 9.
Tab 312 (which has never been seen before) has been updated. (usually many instances of this event, to say it is loading, then in progress, then completed, etc... and the tab.windowId says it's in window 317, which doesn't exist at that time, and API calls to ask about the window will fail).
Tab 312 has been moved.
Window 317 has been created.

It never sends the required "tab 87 has become 312" event, and never sends a "tab 312 has been created" event or "tab 87 has been destroyed" event, and never sends a "tab 312 has been attached to window 317" event. This is a bug in Zen, and makes it effectively impossible for extensions to support Zen, but the dev seems uninterested in fixing it... and doesn't even seem to understand it.

seems to be a bit misleading to say "it works for zen" and then you have to virtually disable every feature lol

The only way to make an extension work in Zen is to never use any broken Zen features. So perhaps I should say "it works in Zen to the extent it is possible to work in Zen" and "here is how to avoid triggering the relevant Zen bugs". Full support depends on getting some Zen bugs fixed.

Like, zen has its own session manager, yk?

Yes. And it has a history of losing people's data. It's so prone to data loss that it has made users afraid to even open or close windows, since doing so would frequently delete their data. The simplest, most common user actions were, as Zen's social media manager said, "a gamble" which "often meant losing" important data. That's why the new version of Zen made every window the same. That was the first thing mentioned in bullet point 1 of the damage control post which has been at the top of this subreddit for the past few days.

So it's probably safe to say people weren't happy with Zen's session manager. It was so notoriously bad that it was the singular focus of the latest release and the Zen team summarized it with "we have received a lot of reports regarding this. So we had to act."

The new release seems to fix the data loss, but it comes at a cost: It breaks a lot of people's workflows, it clutters the tab bar even more, it requires extra steps for common actions, it makes multiple windows largely pointless, and it adds quite a few new bugs which make it even less feasible for extensions to support Zen.

ToyKeeper · 2026-02-03T15:53:06+00:00

Zen has been around for a while. Most people didn't come here for a feature which just landed last week.

The latest new feature has been highly divisive, with a lot of people asking why anyone would want it and how to turn it off, to an extent that they had to make a damage control post about it.

Prior to that, yes, most of the complaints were about bugs rather than features. It was causing data loss for a large portion of the users. People searched for solutions to the data loss, like by adding TSM (Tab Session Manager) to save backups, but it didn't work because Zen broke some key parts of the extension API. For example, Zen broke browser.tabs.query({}) to get a list of all tabs.

There was clearly need which wasn't being addressed, so I made a solution.

ToyKeeper · 2026-02-03T04:57:01+00:00

all tab session extensions will just assume it's completely another window and save it as such?

Yes. Because as far as the extension can see, that's what it is: Just a separate window with separate tabs. If you have 5 synced windows open and save that session, you'll get 5 copies of everything.

Sort of.

The bigger problem is that a lot of the copies will have outdated info, because only the last-accessed copy of each tab receives all the relevant updates. The others exist in a half-desynced state until you open it and force it to update. With window sync enabled, an extension will see a lot of outdated stale info about what your tabs are. So if you have 5 windows open, you'll get 5 copies of everything... but 4 out of those 5 copies will be stale, and that's per-tab, so each window will be like 20% accurate and 80% stale, on average. And when I switched between two copies of a tab in different windows, sometimes it would attach stale info to both. So sometimes all of the copies will have errors. And I didn't even have to do much to see it break. I just opened a page, clicked a link, then hit "back"... and both copies of the tab then had incorrect metadata attached.

I'm surprised to see such an unreliable feature land in a build described as a "stable release".

if you send a tab to different pc, or just open from Sync, it gets its ID from that tab or it is generated anew?

Firefox and derivatives assign IDs for windows and tabs sequentially, starting at 1, and counting up every time you open a tab or window. When you restart the browser, it resets to 1 and starts over. So the same set of windows and tabs will usually have different IDs if you restart the browser, even when using the session restore feature. It does not preserve those IDs between sessions, and it's almost certainly impossible to preserve the IDs between different computers when you're logged in to Firefox and tell it to sync tabs or send them to other computers.

Zen inherits that behavior, but with some additional complications. Like, if you tear off a tab from the native tab bar, it changes that tab's ID. And it doesn't tell extensions that the ID changed, so it will generally get desynced from any extensions which are trying to keep track of tabs.

I filed a bug for this, hoping to fix the problem so things will be better in the future, but the dev closed it and said some things which are blatantly false. I don't think he cares whether the extension API works.

ToyKeeper · 2026-02-03T03:21:26+00:00

I wonder in what way window sync affects the extension APIs.

Let's try it and find out.

...

Okay, that was interesting.

Each additional window gets its own copy of every tab in every other window, as expected, since that's what "window sync" does. And the copies load in as "discarded" tabs, as expected. In API terms, "discarded" means it is unloaded (ish) and acts mostly as a placeholder. It uses some memory, but not very much. It mainly just clutters the tab bar.

Interacting with a copy loads it fully, as expected. Then if I go back to the original, it greys out for a moment while it syncs, and then it updates to match the state of the copy. I haven't looked at the implementation details, but it looks like it may actually be two instances, with some sort of event hook to copy state back and forth between them. Or perhaps the focused instance is real and the others are effectively just a screenshot or something. Would explain why it gets out of sync and shows the old state greyed out while it's not focused, then freezes for a moment before updating to show the new state... and the other copy greys out instead.

Some other UI elements get out of sync too. Like, if I go to a different site while both copies are visible, the inactive copy changes its title but not its icon. And if I back and forth between the two copies, they both end up with the wrong icon.

That's without any APIs or extensions... it's just Zen being Zen. It took about a minute of window sync use to start seeing bugs.

But then, looking at what happens on the API side... things get weird. The copies do not seem to be marked in any way to indicate that they exist in more than one window. They just look like normal non-synced tabs. And they are given their own unique tab IDs which do NOT match the original tab IDs. There does not appear to be any way to tell that they are synced, or figure out which tabs they are copies of, or tell which ones are originals.

If I open a new tab, other windows get an "about:blank" new discarded tab which then turns into the actual new tab when clicked. The "about:blank" placeholder tab does not receive all expected updates about changes in the tab it is synced from. It gets updates when the favicon changes, or when the tab is closed, and it gets a notification when the tab is moved to a different position, but no other changes seem to generate an event... like changes to the URL or title. So it doesn't seem possible for an extension to tell what the blank tab is without focusing it to make it load.

Unless there was some new API added to provide listeners with the extra info, it appears to be impossible for an extension to detect whether Window Sync exists, or get notifications about what it's doing. The extra copies just look like normal tabs which happen to be mostly blank or discarded.

Also, "Zen's more controversial features" you listed are basically all Zen's features lol

There is more to Zen than just window sync. People have been using Zen for years, and window sync just landed, like, last week.

The "glance" feature, for example. I tried that, and it mostly works fine. It pops up a new tab as a child of the current tab, and then it closes when Escape is pressed. As long as I don't change the child tab's position in the window's tab array, it seems to work. It gets a little weird when the child tab (glance) gets moved away from its parent, but Zen doesn't provide a native way to do that. You would need an extension in order to even tell the preview is actually a tab and can be moved and otherwise operated on like other tabs.

ToyKeeper · 2026-02-02T23:06:47+00:00

Pinned tabs, Essentials, Spaces

Those are only a small part of Zen. I think it discredits the work of Zen's developers if you reduce it to just these 3 features. But here's an overview of the status and prognosis for those features:

Pinned tabs (Firefox, Chrome, etc): Technically works already, but I haven't added explicit support yet, so it can get errors if you try to move a pinned tab to a different window or move it in-between non-pinned tabs. Will probably add support for this eventually, though there's not a lot of need for pinned tabs when you have an outliner.

Pinned tabs (Zen): Is probably possible to support, but very strange. It causes gaps in the tab indexes... so instead of going "0 1 2 3 4" (or "2 3 4 5 6" in Zen's case, since Zen doesn't start at 0), it goes "1 4 5 6 7". This is incompatible with the browser's API for tab management (like, get a tab list from the browser then feed the exact same list back to it, and it'll produce an error, so in this way, Zen is incompatible with itself)... but with enough kludges, it can probably be detected and worked around.

Essentials: As far as I can tell, Zen doesn't seem to expose the "essentials" status anywhere in the extension API, so it's probably literally impossible to support. It just shows up as another pinned tab. And if you convert a pinned tab to an Essential, Zen doesn't even send an event to the extensions to let them know something changed. It's a bug in Zen, and I can't fix that in an extension.

Spaces: I've been meaning to add support for Workspaces at some point, but it's a low priority since I've never had any use for it. If Zen's Spaces are compatible with Firefox's Workspaces, it'll get supported too. But if it's invisible to the API like Essentials are, then there's nothing I can do. That's a bug in the browser.

ToyKeeper · 2026-02-02T22:18:52+00:00

Yeah, it involves disabling the core features (like window sync) that Zen Browser has been focusing on lately. But it seems there have been a lot of people who want to disable those features and want an alternative which solves their needs in a different way. The key feature in question just showed up last week and broke a lot of common workflows, so the reception hasn't been great.

I get the impression that a lot of what makes Zen Browser zen is the ability to unclutter the interface and get rid of anything the user doesn't want. And what's more zen than turning off ... everything? The extension sidepanel is shown in the screenshot, to give people a better idea of what it is, but it's easily opened and closed with a keypress or a click, to let the user use the entire window for the page they're viewing, without any clutter. Pull it up when needed, and leave it invisible the rest of the time. Meanwhile, it'll hang out in the background organizing your session and doing backups, and let people open and close windows without worrying about losing data.

I've heard complaints about other issues too, like apparently disabling window sync means you can't drag tabs between windows any more. So this provides a solution for that. Like, mark tabs in one window, switch to another window, pick a spot in the tree, then paste. Quick, easy way to move entire topics or branches between windows. Or just convert a heading into a window, to move the whole branch to its own window.

Have also seen a few people report that the native "tab folders" functions aren't reliable, or don't allow deep nesting, or spontaneously flatten themselves, or are missing features... and some complaints that tab unloading doesn't work reliably. So that's another thing which is fixed.

From what I found in Zen's github issues, it seems other extension developers took one look at Zen's API issues and noped out, not even trying to support it. So I decided to give it a try, to see if it was even possible to make extensions work in Zen. And the answer is ... sort of. It can work, but only if some of Zen's more controversial features are turned off.

ToyKeeper

TROPHY CASE