Orange bar keeps re-appearing on reverting changes in panel

Hey all,

Iā€™m experiencing this issue since quite some time and I live with it as itā€™s not so bad, but itā€™s still annoying. Sometimes when I revert changes on a page via the revert button in the orange bar, the bar shortly disappears, changes are indeed reverted, but then the bar re-appears. Itā€™s only gone for a few milliseconds, so it appears as mere flicker. If Iā€™m in such a state, the bar does not disappear (except for a few ms) until I reload the browser and then hit revert again.

I cannot say, in which circumstances this happens. Itā€™s just from time to time. Sometimes it seems to always happen, then itā€™s working a few times and then breaks again.

I can see in the network tab, that when I hit revert in the error case, there is a POST request to ā€¦/lock and about 30ms later there is another POST request to ā€¦/lock.
I cases, when itā€™s working, there is just a single POST request to ā€¦/lock.

Is anyone else experiencing something similar and can guide me to a solution?

Best regards,
Steffen

Could you please tell us which Kirby version you are using and in what sort of environment? PHP version, server, caching etc?

Sorry, of course. Iā€™m using Kirby 3.6.1.1 and the issue occurs both on my local machine (PHP bulit-in server; PHP 8.0.13) as well as on the server (PHP 7.4). I observed the same since at least 3.5. As I said it has been going on for a long time, but I more or less ignored it until now, because itā€™s not that severe and our customers donā€™t seem to use revert too often.

The issue might be linked to the writer field. I just played around and could only reproduce the behaviour with the writer field.

Hm, I just tried to reproduce this issue in a fresh Starterkit, but couldnā€™t. Could you please post the exact steps to reproduce the issue, like only when you make changes and revert them, or when copy&pasting stuff? I could find an issue on GitHub but that seems to have been resolved. Also, can you reproduce the issue in a fresh Starterkit?

Yes, I could indeed reproduce the same issue with a fresh starterkit.
I applied one small change: add a writer field called ā€œpretextā€ to note.yml
Here is my note.yml:

# Each page blueprint must have a title, the title may be different from the file name
title: Note

# Sorting number scheme that is applied when page status is changed to `listed`
# More about page sorting: https://getkirby.com/docs/reference/panel/blueprints/page#sorting
num: date

# Each page can have an icon that is shown in page listings when no preview image is available.
icon: šŸ“–

# Custom descriptions for each page status depending on use case
# More about page status: https://getkirby.com/docs/reference/panel/blueprints/page#statuses
status:
  draft:
    label: Draft
    text: The note is still in draft mode. It can only be seen by editors with panel access.
  unlisted:
    label: In Review
    text: The note is online and can be visited with the direct URL. The team must still give the final go to publish it.
  listed:
    label: Published
    text: The note is online and listed in the blog

# Define the form layout with two columns
# Columns are optional but help structure the form layout
# More about columns: https://getkirby.com/docs/guide/blueprints/layout#defining-columns
columns:
  - width: 2/3
    # This columns only has a single field
    fields:
      pretext:
        type: writer
      text:
        type: blocks

  - width: 1/3
    # This second column holds a fields section with multiple fields
    # More about fields sections: https://getkirby.com/docs/reference/panel/sections/fields
    sections:
      meta:
        type: fields
        fields:
          # If you need the same field in multiple locations, you can define them once and reuse whereever needed.
          # Here we use a files field defined in `/site/blueprints/field/cover.yml`
          cover: fields/cover
          date:
            type: date
            time: true
            default: now
          author:
            type: users
          # Fields types can be added using the shortcut `fieldname: true`
          # (however, you can only use a fieldname once per page and this only makes sense for simple fields without configuration)
          tags: true
      files:
        type: files
        template: blocks/image

The rest is completely unchanged.
My guinea pig was the ā€œExploring the universeā€ note.
I had to play around a bit with the new writer field: Add text, save, add more text, revert, switch to a different page, come back, add text, revert, save, ā€¦ And at some point within 2-3 minutes the issue occurred. Can you reproduce this? I cannot remember the exact steps, but it was a combination of the above.
BTW: After it first occurred, itā€™s now happening consistently. PHP version is as mentioned above: 8.0.13 with the PHP built-in server.

I took a while, but when I added a list and reverted, I finally got to the point where I couldnā€™t continue without having to save first. Could you create an issue on GitHub?

OK, for me the issue occurred by just editing a simple text node in the writer field. Anyway, the point is that this issue can occur. And itā€™s by far not always so hard to reach. I mean editing, reverting and saving ā€œwildlyā€ is not really a use case, but actually I came across this during normal usage every now and then.

You are right, saving also breaks out of the issue, but itā€™s kind of counterintuitive to do that, when you actually want to revert. I guess this is quite hard to reproduce and tackle as itā€™s happening more or less sporadically. If I find an easy way to reproduce it reliably, I will post here again.

Iā€™m also experiencing this.

I saw it on Kirby v3 and am now still seeing it on v4.

Opened a GitHub issue for it: