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.