Single Part App Page doesn't prevent navigation when there are unsaved changes

[trey-miller]

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

When editing a Single Part App Page, and there are unsaved changes, navigation should be prevented with a beforeunload confirmation prompt as it is when editing a normal Site Page.

Observed Behavior

When editing a Single Part App Page, and there are unsaved changes, navigation is not prevented.

Steps to Reproduce

1. Create a basic SPFx web part, target the supportedHosts.SharePointFullPage in its manifest, and add a PropertyPaneCheckbox in the getPropertyPaneConfiguration method. Package and deploy the sppkg like normal.
2. Create an app page based on the new web part.
3. Click Edit to open the property pane.
   a. Toggle the checkbox on.
   b. Alternatively, simply change the value in the built-in Title field.
4. Without clicking Save, click the reload button on the browser.
   a. Optionally, click the X button to close the property pane before reloading the browser.
   b. Optionally, instead of reloading the browser, click a link in the left side nav bar (e.g. the Pages list)
5. See that navigation is not prevented/confirmed with a beforeunload event, nor with the custom dialog that SharePoint shows when doing the fast navigation.
   a. Also see that the changed checkbox value and/or Title value is not persisted.

Additional Info

When comparing with a normal Site Page, the Site Page will have a status text saying "Draft not saved" when properties have been edited, and after a few moments will say "Your page has been saved." There is no status text equivalent in an App Page, although after a few moments of toggling the checkbox, you will see the onPropertyPaneConfigurationComplete fired. Still, even after waiting for this to fire before reloading the page, the changes are not persisted.

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[andrewconnell]

Talked to engineering today. This is a known issue & on the backlog to get implemented.

[patmill]

the fix for this should now be rolled out fully

[ghost]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues