Old UI (legacy frontend) — field values flicker/revert briefly after ticket update in Zammad 7.0

Technical assistance
1

Subject: Old UI (legacy frontend) — field values flicker/revert briefly after ticket update in Zammad 7.0

Infos:

  • Used Zammad version: 7.0.0-1773670006.ac644a7b.jammy amd64
  • Used Zammad installation type: package (deb)
  • Operating system: Ubuntu 22.04 LTS
  • Browser + version: All browsers (Chrome, Firefox, Edge — tested in incognito as well)
  • Elasticsearch version: 8.19.12
  • Database: PostgreSQL 14

Environment: Hyper-V virtual machine, 7 CPU cores, 14 GB RAM

Expected behavior:

When changing a ticket field (e.g. owner, state) and clicking “Update”, the new value should be applied and displayed immediately without any visual glitches.

Actual behavior:

After clicking “Update”, the changed field briefly reverts to its old value for approximately 1–2 seconds, then snaps to the correct new value. This flickering/revert happens consistently on every ticket, regardless of the field being changed (owner, state, group, etc.).

This behavior appeared after upgrading from 6.4 to 7.0. It was not present on version 6.4.

Important: The new Vue.js desktop frontend (/desktop) does not have this issue — the problem only occurs in the legacy frontend (/#ticket/zoom/...).

What was checked:

  • Server response times are fast: TicketsController#update completes in 270–350ms, TicketsController#show in 25–120ms
  • WebSocket has no delays — push messages arrive instantly
  • Ruby GC was tuned (reduced GC pauses from 300ms to <10ms) — did not fix the flickering
  • Disabling all triggers — did not help
  • Tested across multiple browsers and incognito mode — same result
  • Updated to the latest 7.0 build — issue persists

Steps to reproduce:

  1. Open any ticket in the legacy UI (/#ticket/zoom/<id>)
  2. Change the owner (or state, or any other field)
  3. Click “Update”
  4. Observe: the field briefly shows the old value, then updates to the new value after ~1–2 seconds

Network tab observation:

After a single “Update” click, the frontend sends multiple duplicate requests for the same ticket (tickets/<id>?all=true), each triggering a UI re-render. This causes the field to flicker between old cached data and fresh server data.

Workaround:

Switch to the new desktop frontend (/desktop) — the issue does not occur there.

2

We are seeing this as well. It doesn’t bother me really, but one of my techs complained.

3

We see that too, sometimes tickets gets randomly closed. You can see in history that the user closed it, but the user did not closed it, it switches to closed after changing some values like owner or ticket type, after updating, the state go “sometimes” to closed, you see that in realtime.

4

Same here, two colleges show me this today. We use Zammad 7 some days now and have the Same Problem

5

This behavior is very frustrating when editing multiple fields sequentially - the interface keeps shifting and jumping, which makes it hard to work efficiently.

It also makes user search extremely difficult when there are multiple pages of results. For example, when trying to navigate to the second page, the interface sometimes jumps back to the first page. Then you try to click the second page again, but it turns out you are already there, which creates confusion and slows down the workflow.

The same happens with the database - sometimes I get an error saying that the page does not exist after editing it. I think this is the same issue.

6

Why are you not setting all fields at once and hit update once?

7

We are working on it, we have a fix in the pipeline: Ticket sidebar form field value is flickering when updating the ticket · Issue #5855 · zammad/zammad · GitHub

Should be available in the next few days.

8

The fix was merged, should be available soon in the package installations.