Bug: Hibernation disabled by default — isHibernationEnabled defaults to false, making hibernateOnStartup ineffective

[phelix001]

Avoid duplicates

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issues tracker for a bug report similar to mine, in vain

Ferdium Version

7.1.2-nightly (develop branch, commit 655af84)

What Operating System are you using?

Linux

Operating System Version

Linux 7.0.0-070000rc4-generic

What arch are you using?

x64

Last Known Working Ferdium version

Never worked — this is a default configuration issue that has existed since the setting was introduced.

Expected Behavior

Services should hibernate automatically after inactivity. The hibernateOnStartup: true default setting should cause non-active services to start hibernated. Inactive services should unload their webview renderer processes, freeing ~170MB per service.

Actual Behavior

Hibernation never activates for any service by default. Users see 2-3GB+ memory usage with all service renderer processes running permanently, regardless of inactivity. The hibernateOnStartup setting appears to work (it sets isHibernationRequested = true) but has no actual effect.

Root cause chain:

1. DEFAULT_SERVICE_SETTINGS.isHibernationEnabled defaults to false (src/config.ts:628)
2. canHibernate is computed as this.isHibernationEnabled && !this.isMediaPlaying (src/models/Service.ts:315-316) — always returns false when hibernation is disabled
3. isHibernating is computed as this.canHibernate && this.isHibernationRequested (src/models/Service.ts:319-320) — always false because canHibernate is false
4. _hibernate() in ServicesStore early-returns on !service.canHibernate (src/stores/ServicesStore.ts:1174)
5. The hibernateOnStartup: true global default sets isHibernationRequested = true in the Service constructor (src/models/Service.ts:247-248), but this flag is ignored because isHibernating requires canHibernate to be true

The result: Every service runs a permanent Chromium renderer process (~170MB each) regardless of whether the user has interacted with it. With 8 services, that's ~1.4GB in renderer processes alone, plus overhead.

Secondary issue: Even when a user manually enables hibernation per-service, the wakeUpStrategy: '300' default auto-wakes services after 5 minutes, creating a pointless hibernate/wake cycle that defeats memory savings.

Steps to reproduce

1. Install Ferdium fresh, add 5+ services
2. Note that hibernateOnStartup is true by default in Settings
3. Restart Ferdium
4. Open system monitor — all service renderer processes are running
5. Wait 5+ minutes without touching any service
6. Check system monitor again — all renderer processes still running, no services hibernated
7. Check any service's edit screen — "Enable Hibernation" is unchecked by default

Related Issues

• Possible memory issues/leak #2197 — "Possible memory issues/leak" (symptom of this root cause)
• Bug: Ferdium spawns multiple processes and clogs the CPU #219 — "Ferdium spawns multiple processes and clogs the CPU" (partially related)
• Bug: Ferdium main tab (the App itself) consumes more than 1Gb of memory #647 — "Main tab consumes more than 1GB" (symptom)
• Feature: Set memory limits for services and auto reload on exceeding them #606 — "Set memory limits for services" (feature request that wouldn't be needed if hibernation worked)
• Ferdium cache more than 100 Gb #1814 — "Cache more than 100GB" (related to services never being cleaned up)

Proposed Fix

1. Change isHibernationEnabled default from false to true — makes hibernation work out of the box
2. Change wakeUpStrategy default from '300' to '0' — services stay hibernated until user clicks on them
3. Reduce hibernationStrategy from '300' to '120' — hibernate after 2 min instead of 5
4. Add backgroundThrottling=1 to webview webPreferences — throttle inactive service tabs before hibernation kicks in
5. Change isWakeUpEnabled default from true to false — consistent with wakeUpStrategy change

Expected savings: ~1.2GB for a typical 8-service setup (7 hibernated × ~170MB each).

Note: These are DEFAULT changes only. Existing users with configured services won't be affected — their per-service settings are persisted in the database.

Additional information

PR incoming with the fix.