REGRESSION: Temporary filter changes get wiped out after returning from an event to the events page.

[Simpler1]

Describe Your Environment

• Version of ZoneMinder: 1.37.75 (latest commit: fbde89c)
• How you installed ZoneMinder: Docker: zoneminder-containers/zoneminder-base with eventserver-base
• Full name and version of OS: Linux Mint 20.3 Cinnamon
• Browser name and version: Chromium: Version 130.0.6690.0 (Official Build) stable (64-bit)

Describe the bug
After applying a named filter and then temporarily modifying the filter fields at the top of the events page. The filter change(s) made from the events page get wiped out and the original named filter is reapplied when returning from an event.

To Reproduce
Steps to reproduce the behavior:

1. LIST MATCHES for a named/saved filter
2. When the list of events appears, change one (or more) of the filter values at the top of the screen
3. Open an event from the list
4. Back to the events page

Expected behavior
The temporary filter fields applied from the events page should remain until the page is manually refreshed.

This bug was introduced with commit #4480

[Simpler1]

This problem also manifests itself when viewing the "Frames" page to see what frames have an alarm. From the Frames page, if you scroll down and click on a frame and then go Back to the Frames page, you lose your scroll position because the page is automatically reloaded on Back.

---

The quick fix is just to remove (or comment) line 2095 from:
web/skins/classic/js/skin.js

// window.location.reload( true );

[IgorA100]

Please use the WEB_ANIMATION setting to disable animation if you have problems with it.
43f281c

When I have some free time, I'll continue studying animation using bfcache.
But that won't be until February 2026.

@Simpler1
If you could study animation behavior and bfcache and help, that would be greatly appreciated.

[Simpler1]

Please use the WEB_ANIMATION setting to disable animation if you have problems with it. 43f281c

Disabling animations does not fix this problem.

When I have some free time, I'll continue studying animation using bfcache. But that won't be until February 2026.

Then we need to disable this automatic reload. It's bad.

@Simpler1 If you could study animation behavior and bfcache and help, that would be greatly appreciated.

I'm not interested in animations that slow down the user experience. I just want a functional product without regressions.

[IgorA100]

Disabling animations does not fix this problem.

Ok, I'll fix that.

[IgorA100]

Replace the code

  window.addEventListener('pageshow', (event) => {
    if (event.persisted) {
      // Do any checks and updates to the page
      window.location.reload( true );
    }
  });

on:

  if (typeof ZM_WEB_ANIMATIONS !== 'undefined' && ZM_WEB_ANIMATIONS) {
    window.addEventListener('pageshow', (event) => {
      if (event.persisted) {
        // Do any checks and updates to the page
        window.location.reload( true );
      }
    });
  }

I haven't tested it, but it should work.

[connortechnology]

How about instead of window.location.reload, we do mainContentJ.show()?

I really don't like the reload. I thin it's the wrong thing to do.

[IgorA100]

I really don't like the reload.

Yes, but that's a bfcache issue. Bfcache has a lot of problems, and it rarely works 100% correctly. Sometimes problems crop up, and the only option that works 100% is "reload." Furthermore, bfcache behaves differently in different browsers.
I don't think "mainContentJ.show()" will help, but I can't test it myself because I can't reproduce the issue yet.