Clicking "Copy Link" Results in an Runtime Error [wpcom block editor][web + desktop]

[nsakaimbo]

Description

After a post is published, clicking the "Copy Link" button will result in a runtime error that the user cannot recover from. To clarify, this behavior occurs on both the web and the desktop app.

To Reproduce

1. Draft and publish a new post (or unpublish/republish an existing one).

1. Click the "Copy Link" button that is displayed after the publish event
2. A second or two after "Copy Link" is clicked, an error will be displayed to the user. Clicking "Copy Error" does not result in any useful output, and "Attempt Recovery" does not help unblock the user from this state (they are left on the blank page).

[nsakaimbo]

FYI: @sirreal This issue is a highly-visible breaking bug on web that I happened to encounter when testing the editor -> publish flow.

[battouly]

The issue is both for publishing a page and a post. I verified on different browsers too.

Browsers tested on:

• Google Chrome Version 83.0.4103.106 (Official Build) (64-bit)

• Safari Version 13.1.1 (13609.2.9.1.3)

• Firefox Version 77.0.1 (64-bit)

• Opera Version:68.0.3618.165

[andrewserong]

It looks like this one will be fixed by WordPress/gutenberg#23088 which adds a check for onFinishCopy before calling it in the ClipboardButton component. (The PostPublishPanelPostpublish component doesn't use that prop, which seems to have been what caused the fatal). When we upgrade to Gutenberg 8.4.0, this issue should be resolved.

I'll leave the issue open until the upgrade has happened, so that we can then verify that the fix has worked on WordPress.com.

[fullofcaffeine]

I just tested on a simple stickered site and AT site, both running Gutenberg 8.5.1, and I couldn't reproduce this issue. Publishing and copying the URL to the published post by clicking "Copy Link" works as expected.

Tested on Firefox 79.0b9 and Chrome 83.0.4103.61 just in case (although the issue, as described by @andrewserong, doesn't appear to be related to browser inconsistencies).

We can close this once the upgrade to 8.5.1 is complete. Thank you @nsakaimbo for reporting and others for the help testing!

[sirreal]

This should be fixed as of r211812-wpcom.