When the browser closes by itself

While a profile is open the app asks its browser what is on screen, once every half minute. A profile that is closed is never asked.

The built-in engine answers from its own windows. ARMANOS Browser answers on the local port it already uses for automation, and a browser that cannot answer right now says nothing rather than saying that nothing is open.

A profile that climbs to the top of your recently changed list every half minute would be worse than no memory at all. So this write is not counted as a change you made.

It also stays on this computer. The fields that travel to your account are named one by one, and the addresses of open pages are not among them.

• The change date stays put

  Sorting by recently changed keeps meaning what you did to the profile.

• Nothing new means nothing written

  A set of tabs that has not moved since the last sweep never touches the disk.

• An empty answer keeps the memory

  A browser still starting, or reloading a page, does not erase what it held a minute ago.

A browser that exits with a code nobody asked for, or dies on a signal, has crashed. Pressing stop is not that, and neither is closing the window yourself.

The last snapshot is frozen right there, before anything else touches the profile. The next launch would write over the list before you had a chance to answer.

• The notification names the profile

  It leads to the profile it belongs to, and when the engine named no reason it says how many tabs were remembered.

• The reason, when the engine gave one

  A browser that printed a line before dying hands that line to the message, and it stands there in place of the tab count.

• One message per profile per clock hour

  A browser crashing in a loop folds into the message still sitting unread, instead of burying the rest under copies of itself.

• When nothing was seen nothing is promised

  If the snapshot was empty, and the engine named no reason, the message says the profile and its cookies are intact and stops there.

The question comes before the browser starts, because your answer decides what it opens with. It names the profile, the time its browser went, and how many tabs were remembered.

Both answers are final in their own way, and a question closed with Esc counts as the clean slate.

1. 1

   Bring them back

   The tabs open again in the order you left them.

2. 2

   Start with a clean slate

   The offer is dropped for good, so it cannot keep surfacing at every launch.

3. 3

   Either way the profile opens

   The question decides the tabs and nothing else about the launch.

On ARMANOS Browser they queue behind what the launch already opens with: the address the profile was going to, and ahead of that the start page whenever this launch has one.

The built-in engine has no tab strip, so each one comes back as its own window, opened the way the app opens any window of that profile.

• The same folder

  Cookies and storage are the ones that profile already had.

• The same way out

  A restored window leaves through the profile's proxy like every other window of it.

• The same order

  First tab first: the order is the one you left, not the one the disk returned.

• Only after a launch that worked

  A launch that fails keeps both the tabs and the offer to bring them back.

A browser is not the only thing that can be cut off mid sentence. Three more things are checked every time the app starts.

• A session swap caught in half

  Moving a session in does two renames, and a profile left between them is put back together with the older copy, because the newer one may never have finished being written.

• A tunnel that outlived the app

  On macOS and Linux an ssh that ARMANOS started and that still holds a connection to your server is found by a file only this app names, and shut down.

• Folders from a run that was killed

  Tunnel folders and leftover working folders from a previous run are swept, because otherwise they pile up until the disk has no room for a profile.