Fix Unsupported Block Editor on account created prior to December 2018

[guarani]

Description

Addresses wordpress-mobile/gutenberg-mobile#3425 (fixes for iOS, not Android)

The /sites/{site_id}/gutenberg endpoint is unreliable but was being used to check if Gutenberg was available on a site's backend, and if so, disable the Unsupported Block Editor (UBE).

Since the majority of users will have Gutenberg enabled, it makes sense to remove usage of this unreliable API endpoint. What we do instead in this PR is:

• Show a new Loading In-Progress Screen as the UBE loads, with a message warning users that if Gutenberg is not enabled on their site, the UBE (a.k.a. web editor) will not load.
• Show a new Loading Failed Screen if the UBE fails to load, e.g. because Gutenberg was not enabled on the site, including a message prompting users to check if Gutenberg is enabled on their site.

(NEW) Loading In-Progress Screen	(NEW) Loading Failed Screen

To test

Feature tests

See wordpress-mobile/gutenberg-mobile#3425. The testing steps here are:

1. Sign in using an account created before Dec 2018
2. Locate a post with an unsupported block on an Atomic site
3. Open the post and tap the (?) to open the web editor (UBE)
4. Ensure the UBE opens as expected and you can successfully edit the unsupported block

- [ ] UBE now works on Jetpack sites using an account created prior to December 2018

Regression tests

Go through the following test cases (taken from here) and make sure the New Loading Screen is shown while the UBE loads. In TC004, the Loading Failed Screen should be shown after a 15 second timeout.

- [ ] TC001 - User can edit unsupported blocks on Simple WP.com sites
- [ ] TC002 - User can discard edits to an unsupported blocks on Simple WP.com sites
- [ ] TC003 - Editing unsupported blocks is allowed on Gutenberg-enabled Atomic sites
- [ ] TC004 - Editing unsupported blocks is disallowed on Classic-enabled Atomic sites
- [ ] TC005 - Editing unsupported blocks is enabled on self-hosted sites accessed via Jetpack
- [ ] TC006 – Editing unsupported blocks is disallowed on self-hosted sites accessed via their own username and password

Regression Notes

1. Potential unintended areas of impact

This could somehow cause issues with the Unsupported Block Editor loading, so it's important to test this across all site types.

2. What I did to test those areas of impact (or what existing automated tests I relied on)

The manual test cases above aim to cover these areas of impact.

3. What automated tests I added (or what prevented me from doing so)

This PR adds a loading screen that relies on the underlying network request. Mocking this seems tricky, both as a unit test or a UI test (using https://github.com/wordpress-mobile/WordPressMocks).

PR submission checklist:

• I have completed the Regression Notes.
• I have considered adding unit tests for my changes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[peril-wordpress-mobile]

You can trigger an installable build for these changes by visiting CircleCI here.

[peril-wordpress-mobile]

You can trigger optional UI/connected tests for these changes by visiting CircleCI here.

[guarani]

Testing 82baaaf:

Feature tests

• UBE now works with accounts created prior to December 2018

Regression tests

• TC001 - User can edit unsupported blocks on Simple WP.com sites
• TC002 - User can discard edits to an unsupported blocks on Simple WP.com sites
• TC003 - Editing unsupported blocks is allowed on Gutenberg-enabled Atomic sites
• TC004 - Editing unsupported blocks is disallowed on Classic-enabled Atomic sites
• TC005 - Editing unsupported blocks is enabled on self-hosted sites accessed via Jetpack
• TC006 – Editing unsupported blocks is disallowed on self-hosted sites accessed via their own username and password

---

TC005 - Editing unsupported blocks is enabled on self-hosted sites accessed via Jetpack

I'm getting the Loading Failed Screen here and the error I see in the console is:

TypeError: undefined is not an object (evaluating 'window.wp.data.select')

Will investigate what could be the problem here. Update: This was due to the WP.com login screen being shown, which is expected, and the Loading Screen was not being dismissed.

[guarani]

Testing 8b98659:

Feature tests

• UBE now works on Jetpack sites using an account created prior to December 2018

Regression tests

Taken from wordpress-mobile/test-cases#78:

• TC001 - User can edit unsupported blocks on Simple WP.com sites
• TC002 - User can discard edits to an unsupported blocks on Simple WP.com sites
• TC003 - Editing unsupported blocks is allowed on Gutenberg-enabled Atomic sites
• TC004 - Editing unsupported blocks is disallowed on Classic-enabled Atomic sites
• TC005 - Editing unsupported blocks is enabled on self-hosted sites accessed via Jetpack
• TC006 – Editing unsupported blocks is disallowed on self-hosted sites accessed via their own username and password

[guarani]

Questions:

• Does the copy on the Loading and Loading Failed screens do a good job of explaining why the user needs to make sure their site has the block enabled?
• We can enable the UBE on non-Jetpack self-hosted sites (see Editing unsupported blocks is disabled on Jetpack and Atomic sites accessed via older WP.com accounts gutenberg-mobile#3425 (comment)): I'll do this in a follow-up PR.
• Show a retry button on the Loading Failed Screen screen: It could be an improvement but I've left it out since it's low impact.

[illusaen]

LGTM!

Just as a quick note: I tend to like pulling out string constants into a small struct so I can have them all in one place but that might not be the style in WPiOS.

[guarani]

Just as a quick note: I tend to like pulling out string constants into a small struct so I can have them all in one place but that might not be the style in WPiOS.

I like that, it would've probably made the code easier to read here. Thanks for the tip, I'll keep it in mind for next time.
Thanks a lot for testing

[guarani]

* Does the copy on the **Loading** and **Loading Failed** screens do a good job of explaining why the user needs to make sure their site has the block enabled?

Do you have any thoughts about this, @illusaen? Does the text get the message across or do you think it could be improved?

[guarani]

I'm going to bump the milestone on this because the Android side is in-progress and I think it makes sense to ship this change on both platforms at the same time. Reason being that this is part visual change, part bug-fix, and handling a different scenario on each platform in manual test cases and beta testing would add unnecessary overhead.
cc @SiobhyB

[SiobhyB]

Thanks for the heads up Paul, just want to mention that I'm AFK next week but will tidy up the Android PR and request a review when I'm back. :)

[mokagio]

I'm running the 17.6 code freeze today. This has 17.6 milestone and is approved, but, given @guarani's suggestion to wait for the Android counterpart to be ready and @SiobhyB message about being AFK and there being a bit of tidy up left to do, I'm going to bump this to 17.7. Android 17.6 does the code freeze today, too, so there's no way the Android counterpart will make into that version.

Do let me know if this is not the best course of action and we'll adjust 👍

[guarani]

Thanks for updating the milestone, @mokagio! Apologies for not updating earlier.

[illusaen]

* Does the copy on the **Loading** and **Loading Failed** screens do a good job of explaining why the user needs to make sure their site has the block enabled?

Do you have any thoughts about this, @illusaen? Does the text get the message across or do you think it could be improved?

I think it makes sense to me. :)

[mokagio]

@guarani No worries at all! 🙌

[guarani]

We agreed in wordpress-mobile/WordPress-Android#14762 (comment) to merge this PR for inclusion in 17.7.