Preview button in edit lock modal is saving the post

[mogmarsh]

Describe the bug
If User A is editing a draft post and User B clicks to edit it, they get a modal that the post is being edited, with options to Exit, Preview, or Take Over. (note that Preview is currently hidden on desktop view, but visible in mobile view).
If User B clicks the Preview button, it saves the post and then loads the preview. If metaboxes are present, it actually overrides the edit lock and kicks out User A.

To reproduce
Steps to reproduce the behavior:

1. Add a metabox to the post edit screen.
2. Create a draft post and save it (don't publish)
3. Log in as a different user in a different browser or incognito and edit the same post
4. When you get the modal, show the Preview button if not visible, and click Preview. You will see in the network tab a post to the rest api, and then a post to post.php for the metabox.
5. After the next heartbeat post to admin-ajax.php the original user will get kicked out of the post.

Expected behavior
When the second user clicks the Preview button, there should not be a save. It should go to the preview url.

Screenshots
If applicable, add screenshots to help explain your problem.

Editor version (please complete the following information):

• WordPress version: 5.5.3
• Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default? default

Desktop (please complete the following information):

• OS: Mac OS 10.14.6
• Browser: chrome
• Version: 86.0.4240.198

Additional context
The problem appears to be happening here:

gutenberg/packages/editor/src/components/post-preview-button/index.js

Lines 162 to 175 in 5cd71f4

	// If we don't need to autosave the post before previewing, then we simply
	// load the Preview URL in the Preview tab.
	if ( ! this.props.isAutosaveable ) {
	this.setPreviewWindowLink( event.target.href );
	return;
	}
	// Request an autosave. This happens asynchronously and causes the component
	// to update when finished.
	if ( this.props.isDraft ) {
	this.props.savePost( { isPreview: true } );
	} else {
	this.props.autosave( { isPreview: true } );
	}

The isAutosaveable prop does not appear to be checking the edit lock.

This code snippet will add a metabox and show the Preview button:

function wporg_add_custom_box() {
	add_meta_box(
		'wporg_box_id',
		'Custom Meta Box Title',
		'wporg_custom_box_html',
		'post'
	);
}
add_action( 'add_meta_boxes', 'wporg_add_custom_box' );
function wporg_custom_box_html( $post ) {
    ?>
    <label for="wporg_field">Description for this field</label>
    <select name="wporg_field" id="wporg_field" class="postbox">
        <option value="">Select something...</option>
        <option value="something">Something</option>
        <option value="else">Else</option>
    </select>
    <?php
}
add_action( 'enqueue_block_editor_assets', function() {
    $style = "
    .editor-post-locked-modal__buttons >.editor-post-preview {
        display: inline-flex;
    }";
    wp_add_inline_style( 'wp-block-editor', $style );
} );

[joemcgill]

I've done some digging into the internals of what's happening here, and it looks like the openPreviewWindow() callback of the PostPreviewButton will always attempt a post save if the current post is autosaveable (code). In the case of the PostLockedModal, the isAutosaveable property is determined by checking the value of isEditedPostAutosaveable() (code), which doesn't take account for the fact that a post shouldn't be autosaveable if it is locked.

There are a few ways this could be handled:

1. isEditedPostAutosaveable() could include a condition that checks to see if the post is locked, and returns false when isPostLocked() is true
2. The editor itself could dispatch a lockPostAutosaving() action whenever the post lock is set to true
3. We could add a special property (e.g., isSaveDisabled to the PostPreviewButton and ensure that the PostLockedModal sets this value to true, and include that in the check that runs inside the openPreviewWindow() callback of the PostPreviewButton component to ensure that only the preview window is opened whenever the callback is executed (i.e., when the button is clicked).