Wp-calypso: Editor: prompts to restore/discard changes when there are no changes

Created on 5 Dec 2016  Ā·  95Comments  Ā·  Source: Automattic/wp-calypso

  1. Starting at URL: https://wordpress.com/post/
  2. Publish a post
  3. Click <- Back
  4. Notice dialog that says ā€œYou have unsaved changes. Are you sure you want to leave this page?ā€

restore ays

Often (but not always), immediately after publishing or updating, I see this AYS (are you sure) dialog when I attempt to navigate away from the editor via the <- Back button. Having to dismiss an unnecessary dialog is annoying, but the much bigger problem is that I can’t trust an editor that makes the save state of my content so ambiguous. One of my editor prime directives is, ā€œDon’t AYS for unsaved changes if there aren’t unsaved changes.ā€

This ambiguity follows when you edit an existing post. I haven’t visited the post below in 3 years. When I open it, I get a restore unsaved changes prompt. This happens for lots of my old posts.

screen shot 2016-12-02 at 3 54 04 pm 1dde8cf8ca76495799958edac5a01ef4

What am I restoring? I just want to peek the post right now, not edit it, so I click ā€œDon’t restoreā€. I’ll postpone dealing with it until next time I venture to this post. After reading, I click the editor’s back button to return to my posts search and receive an unsaved changes AYS (Are You Sure). That’s an interruption on the way into the post and one on the way out. Unless I restore unseen changes, I will be twice interrupted on every visit.

Untrustable editor AYS comes up in user testing, it comes up in internal testing, yet its misbehavior endures. Here’s an anecdote from a recent user testing session.

To save or not to save: in the customizer and editor, both Lori and Mike got alerts indicating they shouldn’t leave the page they were on. This seemed surprising and confusing. In the editor, it would sometimes happen just after updating. In Customizer, the adaptive site preview gives the facade that it’s been updated, and the Save/Publish button was overlooked. Lori and Mike didn’t think their sites were ā€œliveā€ – neither noted the ā€œSave & Publishā€ button (they didn’t see it), but I wonder what that might have told them about their site.

Related issues:

Included screenshots are Macnchrome, latest of each.

Editor [Type] Bug

Most helpful comment

I'll add my testimony. I also experience this almost daily. Being unreliable and misleading about content state destroys trust and creates anxiety. This is an impactful bug that has been around for over a year, possibly back to the beginning. It interrupts publish and edit flow (the heart of this software) with an AYS, an AYS! That is an interruption that smashes cognitive stacks with a forced decision while burning a click/tap. We're interrupting two of the most critical and anxious moments in this software (the moments after publish/update) to deliver false state information and force a decision based on that false state. IMO, this is a high priority flow and trust killer.

All 95 comments

Hey @ryanboren thanks for reporting this. I'm trying to recreate the issue using steps 1-4 up top and can't seem to trigger it. To clarify, the <- Back button, is that the browser back button or the <- Back in the sidebar?

The flow I'm doing is, visiting /post, select a site from the site selector, add title, add content, and publish. I haven't gotten the warning when clicking the browser back or the sidebar back button. I also tried waiting for an initial auto-save to kick in and complete before publishing.

Okay did some digging on the "Saved Draft" dialog as well. This dialog will be shown if a post has any autosave meta data present. I spent some time to confirm that both the Calypso Editor, and wp-admin both will trigger auto-saves on published posts, and as such, any subsequent API requests to that post's endpoint will return autosave data.

Both wp-admin, and calypso are quite generous in making these autosaves as well, so even if you have a post open in either, errantly hit the space bar while focused in the editor, an autosave point will be created. Funny how these autosaves are here to create trust in the editor, but can cause confusion as well.

That being said, this dialog is persistent. So even if you click "Don't Restore" - the next time you open the same post in the calypso editor, the dialog is shown. The only way to clear out the autosave meta is to perform an update on the post. I'm not sure if "Don't Restore" should clear out the autosave meta, but perhaps a third action should be available here for "Delete Auto Save"?

@ryanboren Any further thoughts here based on @timmyc's questions?

I don't think I'm errantly hitting keys--certainly not every time this happens, which is almost daily.

For my flow, deleting when I say "Don't Restore" is okay-ish. I can't speak for other flows though. This is un-transparently destructive. Until we have transparency, perhaps "Delete Auto Save" (or "Discard revision"), but then I'll be wondering what the difference between "Don't Restore" and discard is and why both are present. If we had transparency, I think "Don't restore" could be simply "Discard".

Interim transparency could be showing the time the unseen revision was made. If it's seconds after the last update, I can be pretty sure I want to discard it. But, I pretty much always want to discard because I know the AYS is always wrong.

I've worked out one way to consistently reproduce this after whittling down html tags to which ones trigger this.

Reproducible Steps

1) Create a new post with the following HTML content:

[code language="javascript" light="true"]return this.driver.isElementPresent( this.quoteSelector );[/code]

e

[code language="javascript" light="true"]return this.driver.findElements( this.quoteSelector ).then( e => !!e.length );[/code]

2) Switch to visual editor and publish that post
3) Navigate away from the editor to the /posts list and click "edit" on that post
4) The post should load in the visual editor
5) Switch to the HTML editor, make no changes, switch back to the visual editor
6) Attempt to navigate away

The unsaved changes prompt is displayed even though no changes were made, we only switched between the editors.

editor edit

Interesting @alisterscott - I can reproduce, and it actually triggered the message for me after the initial save too. It appears that it will happen with any shortcode, as I was able to trigger the warning by doing the same flow as above, but on a post with a gallery shortcode.

Moving from Visual -> HTML with a gallery will throw the warning also. /cc @aduth any thoughts on why toggling between Visual and HTML with a shortcode would flag the post as dirty?

@timmyc: Another strange thing I saw with this, but I can't reproduce it so I'm hesitant to raise it, but when publishing a post with similar content, sometimes it shows the message "Post Updated" _before_ immediately showing the "Post Published" success message. Could this be related?

I was able to trigger the warning by doing the same flow as above, but on a post with a gallery shortcode.

I know that @ryanboren does a lot of galleries so this may be why this was happening for him. Ryan: do you switch between visual and html tabs when editing?

The "update" button always shows as enabled even without making changes now, is this part of the new editor design or was it always like that?

There's some duplication between this issue and #6869

/cc @aduth any thoughts on why toggling between Visual and HTML with a shortcode would flag the post as dirty?

When last this was debugged with a fix explored in #6880, I don't recall it being specific to shortcodes specifically, but more around wpautop and how transitioning from HTML to Visual sets the "raw" content without <p> tags which when later compared with HTML from TinyMCE is not strictly strictly equal to each other (latest relevant comment).

Howdy! A user came into chat today to report that she's seeing the same issue. She's on Chrome desktop, and clearing her cache and emptying her cookies doesn't resolve the issue.

She said that when she edits a page, then clicks UPDATE, she gets the message that the page updated successfully. But when she tries to exit out of the page, she gets the alert that there are unsaved changes on her site. She exits the page, and when she returns, she gets the other message letting her know that "there is a more recent version of the page, do you want to restore it?" Understandably, she's upset and concerned that she might lost her changes or content and doesn't understand why she keeps getting these alerts. She returned to chat later in the day to ask about the issue again.

Ticket: #3151780-t

Another user came into chat today with the same issue: they keep getting the message saying that they had "unsaved changes" as they tried to navigate away from a page, even though they'd already clicked the UPDATE button to save their changes before getting that message. They said that when they navigate away, sometimes the page changes are saved, and sometimes they're not. They're really wanting some reassurance that when they save their updates, they'll actually be saved.

I asked them a few more questions to try and see if there was some kind of unique behavior that might pinpoint the cause. User is on a PC, Chrome browser. They said this at one point:

I do notice as I move between pages when I am creating/editing that multiple tabs open up at the top of my page and it gets crowded

I tried to get clarification as to what they meant by that. Are they opening up multiple pages in different tabs to edit them, and then toggling back and forth between them? They followed with:

Happened again. Steps I did. On a page, selected to publish, then choose page attributes to not be a TOP page, updated. I notice the saving changes message came up and went. Tried to move back a page and then warning about unsaved changes came up.

We ended up getting disconnected in chat, so I couldn't follow up with more clarifying questions. I sent the user a ticket so see if they had more insights they could share, so I'll update this if I hear from them again.

Ticket: #3238963-t

This still happens to me almost daily in Chrome and the Mac desktop app. I click Save/Update on a post, wait for it to complete, and immediately try to close the tab or navigate away from the post. I have not touched the keyboard or clicked anywhere else and the AYS will come up.

There are even times where I keep clicking Save, wait, and try to leave, but the AYS will keep coming up again and again. Usually I just give up and leave hoping I don't lose something. :-(

A user reported the same issue using Firefox 53.0 in Windows. From investigating the revision history, it looks like this occurred when proc'ing an autosave call. The latest revision was created by an autosave and has is identical to the current revision.

Ticket: #3266324-t

I'll add my testimony. I also experience this almost daily. Being unreliable and misleading about content state destroys trust and creates anxiety. This is an impactful bug that has been around for over a year, possibly back to the beginning. It interrupts publish and edit flow (the heart of this software) with an AYS, an AYS! That is an interruption that smashes cognitive stacks with a forced decision while burning a click/tap. We're interrupting two of the most critical and anxious moments in this software (the moments after publish/update) to deliver false state information and force a decision based on that false state. IMO, this is a high priority flow and trust killer.

With the new preview after publish in 2.7.0-beta1, the AYS is coming up when I try to navigate from the Preview to My Sites.

I've been trying to reproduce this, but haven't been able to. The only bug I can get to happen is the one that's triggered by switching between the Visual and HTML tabs, but that seems like a separate issue (#6869).

@ryanboren, @nickmomrik: Do you have any insights that might help reproduce it reliably? Would you mind writing out the explicit steps again (since Calypso has changed a lot since the original report)? I think it'd also be helpful to have a handful of URLs for posts that you see this happening on.

Do you have any insights that might help reproduce it reliably?

Unfortunately there is nothing reliable about it. :-/ Sometimes it happens and sometimes it does not. There is nothing different I'm doing between the cases, because I've resorted to doing absolutely nothing else on my computer while waiting after the save/update/publish click to make sure I'm not triggering anything.

Could we add a setting to turn on some debugging that alerts us about what it thinks has changed since we hit save/update/publish?

This came up again in 562944-hc.

I've been running into this about 2-3 times a day when publishing with wpcalypso — I'll see the post-publish screen with the site preview, and when I click on the back button, or try to navigate away I get the "Are you sure?" message about unsaved changes.

Sometimes I just click "Update" again on the post, and it works. Other times that doesn't work.

I haven't narrowed down why or how it triggers yet.

I struggled to reproduce reliably when I tried too but also see it regularly when I'm not trying to.
I'll take another look at this in the hope that I continue to see the prompt.

A few prime candidates for issues:

  • When many editor fields change, we trigger a debounced (delayed) autosave, but this is never cancelled if we then proceed to save the post prior to the delay elapsing
  • Similarly, when the user types into the editor, there's a 200ms delay until we set the new content into the PostEditStore, which is also not canceled when saved

In many cases, this has no impact because the autosave logic shortcuts itself if the post is not considered dirty. However, the content field in particular can be an issue because of escaping and wpautop behaviors. This becomes an issue because we wait until after the autosave delay to retrieve content from TinyMCE for performance reasons.

The steps @alisterscott described in https://github.com/Automattic/wp-calypso/issues/9833#issuecomment-286614962 are pretty reliable here. If you update an existing post with the code shortcode* including some encoded characters (>, &), the post-publish preview reloads itself after a few seconds. What's happening is that because the autosave is not cancelled, and because there's a difference in retrieved content due to character encoding, the autosave request is allowed to occur. Because an autosave does not immediately update the content of a post for published posts, the post is then considered dirty, even though as a user, we'd just updated the post.

There's a handful of things which we need to be doing better here:

  • We ought to have consistent treatment for content formats as described in https://github.com/Automattic/wp-calypso/issues/6869#issuecomment-327210665
  • We ought to cancel pending autosaves once the user clicks to Save or Publish a post
  • We ought to cancel pending "raw content" updates when the user clicks to Save or Publish a post

_* The sourcecode shortcode surfaces the issue because it uniquely encodes and unencodes content._

17819 seeks to address the need to cancel pending saves when the user explicitly clicks Save and Publish, or those effects are otherwise fulfilled. It is not a true fix for this issue, since the fact that those autosaves are occurring after a save or publish is indicative that the editor considers changes to exist.

17820 will resolve some simple cases where merely switching between Visual and HTML modes would cause the post to be flagged as having changes. Again, this is not a proper fix for #6869, as described by difficulty in managing content changes at https://github.com/Automattic/wp-calypso/issues/6869#issuecomment-327210665 and https://github.com/Automattic/wp-calypso/issues/6869#issuecomment-327259455.

I've spent some time analysing the auto-save behaviour in the editor and I still don't understand when the 'Save' button should show and whether this should ever remain or always disappear with auto-save?

This sequence of events creates a sitation where 'Save' is shown but auto-save never kicks in:

  1. Open an existing _draft_ post
  2. Add 2 characters to the body text
  3. Let it auto-save āœ…
  4. Remove those same 2 characters
  5. Save button is shown ā“
  6. Auto save never saves
  7. Leaving the editor results in a AYS question

Is it expected that the save button can remain visible and auto-save not save? In what cases is this expected?

The intended (not-necessary-actual) behavior is:

  • Consider post as "dirty" (needing save) if any fields do not match the value of the original post

    • This means if a value is reset back to its original state, it should not be considered dirty

    • For drafts, "original post" is reset when saving draft

    • For published posts, "original post" is reset when Update-ing (meaning that if autosave kicks in, the post is still flagged as dirty)

  • For drafts, reflect unsaved changes with "Save" button in UI
  • After a change occurs, trigger an auto-save three seconds later

@alisterscott to your specific observations:

  • When the new editor layout was introduced earlier this year, I recall that it broke the "Save" button appearing when changes exist for a new post. I believe it starts showing correctly either after the first autosave, or content has been added to the Visual editor
  • No, the save button should not perpetually linger for a draft. An auto-save is expected to occur.

A possibly related unsaved changes bug related to scheduled posts: https://github.com/Automattic/wp-calypso/issues/17889

That one is easy to reproduce

Reported by user in #699996-zen.

This one is really hard to track down, still — but I do run into it about every week at least once. Usually when using HTML mode rather than visual.

Indeed Lance!

I run into this nearly ever single time I publish. And this is indeed annoying ā˜ŗļø.

@jblz Would you be willing to assign this to Samus? Aduth has notes above for next steps. It's a pernicious one, and in my view a regression vs the wp-admin experience.

I am seeing this more and more, including _during_ live 1:1 sessions with Business users, and it's awkward to explain when the user wants to know why they continue seeing it. (I can see this happening in our screenshare.) I can hear and empathize with the clear frustration in their voices when they continue to see this pop up, especially if/when they see that they are getting data loss when navigating away from the post or page in exasperation.

The most recent report is here:

741705-zen

In the meantime, I often recommend using the WP Admin dashboard as a workaround to those users who are experiencing this more frequently.

This impacts post-post flow.

https://github.com/Automattic/wp-calypso/issues/16040#issuecomment-338731955

This bug is part of our post-post flow. As long as it lingers, we should design with it in mind.

Another user report on #1023642-hc

Another user report: #1093263-hc

User indicates it happens about 80% of the time, and doesn't seem to be relegated to a specific task or site. It's happening to them while editing both pages and posts.

They also mentioned that sometimes they can avoid it by clicking the back button multiple times really quickly, although that's not an ideal solution.

I struggled to reproduce reliably when I tried too but also see it regularly when I'm not trying to.

I'm in the same boat as @spen. 🤨

I am able to reproduce the problem described in https://github.com/Automattic/wp-calypso/issues/9833#issuecomment-286614962 (video: 1m35s) but I definitely don't think it's a good case for what users are running into more often. It's _got_ to be something more common like Twitter or YouTube embeds (which @ryanboren uses a lot) or starting with content copied from other sources on the web. Still trying to figure out reliable steps to repro!

Steps to reproduce:

  1. Go to My Sites > Blog Posts and open any post.
  2. Add a tag in Posts Settings > Categories & Tags.
  3. Click the "Update" button at top right.
  4. Click the "Close" link at top left.

Result: there is a prompt saying "You have unsaved changes. Are you sure you want to leave this page?" even though I have just clicked the "Update" button and that resulted in a success message saying, "Post updated! Visit post."

screen shot 2017-12-21 at thu dec 21 4 40 43 pm
Seen at https://wordpress.com/posts/my/design5279.wordpress.com using Firefox 57.0.1 on macOS 10.13.2.

Steps to reproduce:

  1. Go to My Sites > Pages and open any page.
  2. Go to Page Settings > Page Attributes and select any page as the parent page.
  3. Click the "Update" button at top right.
  4. Click the "Close" link at top left.

Result: there is a prompt saying "You have unsaved changes. Are you sure you want to leave this page?" even though I have just clicked the "Update" button and that resulted in a success message saying, "Page updated! Visit post."

screen shot 2017-12-21 at thu dec 21 4 42 54 pm
Seen at https://wordpress.com/pages/design5279.wordpress.com using Firefox 57.0.1 on macOS 10.13.2.

/hat tip @Lochlaer for noting the page attribute case at https://github.com/Automattic/wp-calypso/issues/9833#issuecomment-305346721.

@Lochlaer! If you find aaaaaany other tips like the one at https://github.com/Automattic/wp-calypso/issues/9833#issuecomment-305346721 about how someone edited page attributes right before seeing the unsaved changes prompt, please note them here. That was really helpful!

@designsimply: thanks for the repro steps

Adding a tag to a post I didn't see the unsaved changes prompt:

add tag

but adding a new parent page to a page I was consistently able to see the prompt:

parent page

I ran into something like this today while testing scheduled posts. I simply stubbed title and content, scheduled the page, clicked Close, and received an unsaved changes confirmation.

Here's a short repro video:
https://cloudup.com/cjdvREhtD4m

If you are having trouble reproducing the bug, try writing several actual posts either on P2s or your personal blog or a test blog. This happens a lot and you are bound to run into the problem if you are writing content with WordPress.com often.

It might be just because I'm doing something different, but I've the impression it's happening more often lately.

Is there any way to put this issue as MEGA-EXTRA-HIGH PRIORITY? It's one of our primary flows, and if a user trust is broken this often our platform experience is massively degraded.

I can't say it's happening more or less for me because it has been happening a lot for over a year. I think I'm becoming blind to it at this point. :-(

Would love to see this get priority since one of the goals is getting people to publish more and it has to be scary to our users when the editor is always telling you there are unsaved changes right after you save. Happy to help with debugging in any way I can.

I ran into this over and over and over on the weekend, when I was setting up a blog with a lot of back-dated posts (specific dates/times). I was creating the posts one after the other, so this behavior was very noticeable, and extremely disruptive.

  • Go to editor
  • Enter content
  • Set publish date
  • Hit Publish (and confirm)
  • Click "Close" in the top left so that I could do the next one
  • Get a warning of modified content

Every single time.

In case it's relevant, I was doing this on a Jetpack site.

Also note that the UI is very different from the original issue now, but this bug persists.

I've moved this to BLOCKER because unless I got lucky, it sounds like this has increased in prominence, and is likely affecting all publishing.

Noting an internal reference because this came up in Slack (p1517080944000112-slack-calypso).

After applying both #21944 and #21937, I can no longer reproduce the following cases:

However, I can still reproduce the following cases:

Edit:

If I understood what @aduth said correctly ("For drafts, "original post" is reset when saving draft"), the second buggy case is actually not a bug as when the draft auto-saves, the "original post" is reset to the new one and then, if you remove those two characters it's considered as a new post /cc @alisterscott. The bug with step 6. "Auto save never saves" is unrelated to the AYS bug here so I wouldn't worry about that right now.

That means there is only one bug related to AYS remaining: https://github.com/Automattic/wp-calypso/issues/9833#issuecomment-286614962. I've looked through it, reading all the GH convos and texts but it's pretty complex. I would say @aduth is the most experienced person for fixing it :) but if you can't find the time, I can try.

Thanks for following these up @lamosty

That means there is only one bug related to AYS remaining: https://github.com/Automattic/wp-calypso/issues/9833#issuecomment-286614962. I've looked through it, reading all the GH convos and texts but it's pretty complex. I would say @aduth is the most experienced person for fixing it :) but if you can't find the time, I can try.

I can still reproduce this one. Do you know if it's specific to the code shortcode in my repro steps, or whether it's broader for other shortcodes too? If it's other shortcodes too it may explain the prevalance of the AYS prompt, as the other fixes were fairly specific (scheduling on UTC+0 sites, and publishing child page). Thanks.

I've changed the priority of this to normal as the worst cases were fixed.

I can still reproduce this one. Do you know if it's specific to the code shortcode in my repro steps, or whether it's broader for other shortcodes too?

It happens for characters which get encoded when being saved to DB, such as < and > but only if you switch between the Visual and HTML modes. For example, if you have text such as "Ribs > Chicken!" and switch to the HTML mode, it will mark the content as dirty because in the HTML mode, the characters are decoded but in the original content, they are encoded.

Easy fix would be to simply use the encoded versions of < and > in the HTML mode (wp-admin does that). The problem is the sourcecode shortcode: its value must be decoded when switching to the HTML mode. Since #8325, we do that but globally for the whole content, not just the code shortcode. More info in https://github.com/Automattic/wp-calypso/issues/6869#issuecomment-327287672.

I've changed the priority of this to normal as the worst cases were fixed.

I understand why, but I'd encourage to not see it as "Normal" since this is probably the most important flow in the whole WordPress, and glitches here impact on the overall experience.

That said, THANK YOU precisely for this reason for working on it. You're amazing! 🌟

Looks like I've found a couple of other ways to trigger this behavior involving page slugs:

  • Open a page in the editor
  • Click the page slug & either:

    • Alter the slug to include a subpath (e.g. some-path/some-slug)

    • ...or Alter the path to include an invalid character (e.g. some-slug!!!)

  • Click Update
  • Click Close

I'm seeing the "Are you sure" prompt every time I do either of these

https://github.com/Automattic/wp-calypso/pull/24563 should fix another minor instance of this issue, related to geolocation settings.

After changing the geolocation, does the editor show the post as "dirty"?

User is reporting this in 4358194-hc
Follow up at 1222808-zd

On all of their pages, they're trying to turn the Like button off. The Update button is always available to be pressed on their pages. If you click Update, the warning ā€œYou have unsaved changes. Are you sure you want to leave this page?ā€ pops up. Able to replicate on their site in SU and SSP.

Further information from user via follow up ticket mentioned above:

How long has this been happening? I have only been working on the site a couple of weeks and it has happened on and off during this time.

Does it come and go? As reported the two bugs* are intermittent.

Does it happen on all of your posts/pages, or just specific ones? As reported it happens randomly.

Does it happen for changes other than unchecking the Like box on the page? As reported I have not seen any other reversion to saved changes.

The * = They're reporting the changes they're making when seeing this notification eventually get reverted. I haven't seen this from my end, but user said they'd keep us posted.

Another user with the same case as @scosgro's above.
4357503-hc

Another user reporting unnecessary "unsaved changes" prompts in this ticket: 1227163-zd

Another report of unsaved changes dialogue appearing after publishing, and prompt to restore newer version when opening post: 4583278-hc

Hello! Good day to All!
Another user reported the same issue as described on this page. I tested it on my side and same thing is happening. Ticket 1243468-zd.

1252792-zen

Hi. Sometimes my blog posts do not save. I click the save button and it says it
has saved but when I click close it says changes not saved?
Can you help? I am always unsure if the final version is the correct one that is
published on my blog

I have another report of this issue. I was able to replicate on their site and on my own site. Interestingly, it seemed to only happen when editing a post to add, remove, or change media items. When only typing text, I do not get the alert.

The user also reported if they Preview the site then click View Site from there, they do not get the error. They mention that this happens in both Firefox and Opera, but is not happening on every post or project.

Ticket: 1244893-zd

Whenever I try to exit the page after editing and updating, my browser and WordPress app on my iPhone would always show a pop up which says I may lose unsaved changes

1252827-zen

1184543-hc

Every time I make changes to a pages and hit update changes, when I close out of the page, it says I have unsaved changes. When I click cancel, and hit update again, it still says the same thing every time I go to close the page. The changes seem to go into effect, but I'm not sure why it says I have unsaved changes every time I update a page, even when I hit close seconds after it update

User's setup:
Operating System: Windows 10 (64-bit)
Web Browser: Chrome 67.0.3396.99
Screen Resolution: 2560 x 1440
Browser Size: 2560 x 1334
Javascript: Yes
Cookies: Yes
Color Depth 24
Flash Version: Not Installed
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/67.0.3396.99 Safari/537.36

Following up on @separatelyunited 's user comment above, the user came back and said they'd been testing this issue "for shits and giggles" and followed up:

using my Opera Browser, I created an entirely new portfolio, same name and ten images, and saved it. And then updated it. Same results, same error message, but the changes were saved and do show on the site. I thought it was something about that particular portfolio, but it isn't, and I suspect that it will hold true for all portfolios created or edited in at least foxfire and opera. I'll let you test chrome and internet explorer.

Ticket: 1244893-zd

I have another report of this issue.

When creating a draft post: user clicks on "Save" in which it turns to "Saving" and then reverts back to "Save". When exiting post-draft, the dialogue box appears notifying user to "Save Changes". If we close the notification that changes aren't saved and return, we see that the text has been saved regardless.

I was able to replicate this on their site but not on my own site.

User's Setup: PC, Windows 10 on Google Chrome.
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

HC: 4924708-hc
Followup Ticket: 1272806-zd

Had another report of this from a user.

I write the blog post. I publish it. After it's published. I go to close the writing window and a dialog box drops down claiming that my changes haven't been saved and will be lost if I close the window. If the program was coded properly instead of using scripts all over the place, it would know that it had already been saved and published.

Ticket: #1272733-zen

https://github.com/Automattic/wp-calypso/issues/9833#issuecomment-404021034

The same user came back and mentioned they are having the same issue on their app as well, have asked what app are they using for more information.

1272806-zen

Edit from Donal: user confirmed it is with the Android app.

Adding one more case. User reports that the one message says the page is updated, the other message reports that changes aren't saved.

1272733-zen

I still run into this several times a week in both Mac Chrome and the Mac desktop app. This bug has been open over a year and a half now. While there have been improvements, it still happens a lot. From the recent comments here it seems our users are reporting it more than ever. I've never lost anything in a post but I can't help feel for the users who are being told their data was not saved. After you get the message, even when you click save and wait for it to save, you still get the message again.

Does anyone commenting here (including @nickmomrik) have Markdown off for your WordPress.com site? I've seen a pattern where sites with Markdown support turned on have the AYS prompt all the time.

It was enabled for both sites I publish to. I don't use it though, so I've turned it off and will see if I notice a difference.

6869 shows how it's easy to make the editor state dirty merely switching between Visual and HTML modes using shortcodes like gallery without making changes so I think that may influence some of these reports, particularly for advanced customers using HTML mode:

switching modes dirty

I had two more reports this week in on the French forums:

Had them both try other browsers/computers/internet connection, but the issue is still here.

Another user report of this in 1277576-zen. This is happening on all of their posts, even immediately after updating/publishing.

Another report in #1278537-zen. They say it has been happening for the last few weeks.

Re-posting the report by @slicesofamerica which had int links:

I have a case to report of this issue from ZD ticket 1276973.

1276973-zd

4978069-hc

User is getting the warning, "You have unsaved changes. Are you sure you want to leave this page?" every time they save. They cleared the browser cache and it should be noted that another user on the same site, different computer, is getting the same error.

Two more reports:

5045852-hc - User keywordsdc

5047354-hc - User margohal

This happened in Chrome, Firefox, and Safari when in Calypso. I replicated it myself. It doesn't happen in WP-Admin.

OK, I think I've got a bead on at least one of the major causes of this as per recent reports...

Spacing in inline styles is prone to keeping the editor marked as "dirty."

Here's a simple way to reproduce:

  • Create a new post (or page, etc. -- it happens there as well)
  • Switch to HTML mode
  • Paste: <p style="padding-left: 30px;">hi</p> (note the space between the : & the 30px)
  • Publish the post
  • Attempt to navigate away

I'm seeing the prompt 100% of the time for this case.

I tried manually calling wp_insert_post on WPCOM and the space in the inline styling is getting stripped there.

When Calypso attempts to resolve the post_content from the response with that in the state.posts.edits value it decides the buffer is "dirty" and keeps the edit in state.


As @alisterscott pointed out with regards to shortcodes, switching to the visual editor is one way this can be elicited.

I suspect that something changed in the visual editor that, while not the cause of these symptoms, has exacerbated it by putting these sorts of whitespace in the content.

...continuing to dig.

Keeping the "dirty" flag correct has been a topic of many subtle bugs for a very long time, but the latest issues were caused by the Reduxification work. The algorithm for the following flow has changed:

  1. User changes a post, clicks "Save".
  2. While save is in progress, the user continues typing and making changes
  3. Save finished, the REST response has the "canonical" saved post object
  4. Somehow we need to "rebase" the unsaved changes onto the saved ones, removing saved edits and keeping the unsaved.

The old Flux algorithm stored the edits-while-saving into a queue and applied them to the post returned from server after save finished. Similar to "git rebase"

The new Redux algorithm is different: it continues to apply the edits to the "current" post, and when save REST response arrives, tries to merge the two versions of the post by comparing attributes. Similar to "git merge"

This works well for all attributes except content: there are filters and normalizations being applied on the server that make the content returned in REST response different from what was sent in the request body. That defeats the "dirty" check and there is no way to distinguish the "important" edits from "unimportant" ones.

I'll work on a PR that improves the Redux algorithm when saving content.

Another case to report: 3858433-hc

User said it's been happening "over the past couple of days" after publishing a post. Using chrome.

User #1276973-zen back with this additional info:

Yes, both my co-administrator and I are working on PCs running Windows, not Macs.

Another user facing this issue- 1286248-zen

The User facing an issue while writing posts. When they edit the post, click Save to save the changes, then hitting the Close button gives them the 'AYS' warning.
This is mostly happening with the post- Portugal Part 1.
I tested it by impersonating them and can confirm that it is happening.

I researched the "space-in-style-attr" bug reported by @jblz in https://github.com/Automattic/wp-calypso/issues/9833#issuecomment-405359776 and it's interesting that it happens only on Simple WP.com sites. Jetpack and Atomic sites keep the whitespace as-is, don't clean up the content and don't trigger the AYS bug. Apparently the server-side filters for content (there are several) are different for each site.

I'm working on this today.

One more user is facing this issue- 1290581-zen

The user is getting the warning, "You have unsaved changes. Are you sure you want to leave this page?" every time they save.
They say it has been happening after adding categories to the post.
I tested it by impersonating them and can confirm that it is happening.

Another user is facing the same issue here - 1293710-zen

User is having an issue with the page "Queenies Closet" while saving it, seems to trigger the AYS dialogue box. Asking to save again even though they have just saved it.

After making the Markdown changes, it's still happening for me.

Please test some of the fixes in #26247 by @jsnajdr šŸ™

After making the Markdown changes, it's still happening for me.

@nickmomrik I couldn't reproduce the bug when editing a post with Markdown enabled. (I enabled it in wp-admin in the Settings -> Writing section on a Simple site, maybe there is some different "Markdown support" I'm not aware of).

It would help me a lot to have reliable steps to reproduce, and a GIF video always helps, too :wink: Also, it matters a lot whether the site is Simple, Atomic or Jetpack one -- each type has slightly different plugins and that influences how posts are transformed on save.

I disabled Markdown as a test (and since I don't use it) based on https://github.com/Automattic/wp-calypso/issues/9833#issuecomment-404628252

I've been experiencing these AYS issues with 2 WordPress.com sites. It would be great if there were reliable steps to reproduce this, but I've never been able to notice a pattern.

For this user in #1276973-zen back the site is a simple site and the problem is happening for multiple admins. They say the problem is sporadic and does not seem to have any pattern. It is not specific to one page. They also said they as far as they can see even though they get the message that changes were not saved, they have not actually lost the changes they made.

I am asking them to try making some edits and letting us know if they get the error. I have not been able to produce it on my end.

Considering the frequency of the previous user reports of this bug, and that we haven't seen a user report on this for 21 days since @jsnajdr's changes, I believe we can be confident that those changes have addressed this long-standing šŸ›

šŸŽ‰ and šŸ™ @jsnajdr

Still happens to me almost every day.

Still happens to me almost every day.

Hi @nickmomrik, if you have reliable steps to reproduce (having these makes all the difference between fixing and not fixing a bug), please file a brand new issue. This one already became a confusing mix of many different bugs that are not always related to each other.

Unfortunately there has never been a reliable set of steps.

I've got a customer still reporting this too, though I also don't have reliable repro steps.

There's a very slight chance that this will help anyone, but I've encountered the same problem in the classical editor of WordPress while using the submitanyway library.

The code that was triggering it was as simple as:

$(selector).submit(function(ev) {
    ev.preventDefault();
    this.submit();
}
Was this page helpful?
0 / 5 - 0 ratings