Fix Unsupported Block Editor on Accounts Created Prior to December 2018

[SiobhyB]

Fixes the Android side of wordpress-mobile/gutenberg-mobile#3425

gutenberg: WordPress/gutenberg#32395
gutenberg-mobile: wordpress-mobile/gutenberg-mobile#3573

Description

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. That's done by removing the check for the Gutenberg editor in this PR.

To account for the removal, the loading and failed screens are updated in the Gutenberg PR.

Testing

To verify that the UBE now loads for Jetpack sites on an account created prior to December 2018:

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

The UBE test cases outlined here were used as a guide for further testing:

- [ ] 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

When going through each test case, verify that the following is true:

• The message warning users that Gutenberg is required is displayed when the UBE is loading.
• When testing TC004, the failed screen is displayed to users after the progress screen has been visible for 10 seconds.

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)

Manual testing was carried out, following the steps outlined in the Gutenberg PR.

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, which seems tricky to account for using automated tests.

PR submission checklist:

• I have completed the Regression Notes.
• 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 optional UI/connected tests for these changes by visiting CircleCI here.

[peril-wordpress-mobile]

You can test the changes on this Pull Request by downloading the APKs:

• Jetpack-pr-14762-build-111875.apk
• WordPress-pr-14762-build-111875.apk

[SiobhyB]

@hypest, I wanted to check in with you for help on the approach to take for editing the progress and failed screens. There are two options that I see:

• The PR I created proposes changes to the GutenbergWebViewActivity.java file, which lives in the Gutenberg repository. The reason I went ahead to make changes directly to this file is that I saw this is where the existing progress bar and screen live. It seemed simplest to flesh those screens out directly in that file. A problem is that this diverges from the approach that's taken on the iOS side, which makes use of an existing progress screen in the iOS repository. If we stayed with this approach, @guarani would possibly make changes to the existing iOS PR to be more in line with Android.
• I haven't experimented with this too much yet, but I believe we could follow the iOS approach a bit more closely by making changes directly to the WPGutenbergWebViewActivity.java file and adding a new layout in the WordPressEditor library. It seems like this would be a bit more complex, but possibly a better route that would mean no more changes on the iOS side.

Does either approach stand out to you as being preferable to the other? Looking forward to hearing your opinion!

Slack thread for reference: p1623681835423800-slack-C6UJ0KRKQ

[guarani]

Thanks for writing out the two options there in the PR comment, @SiobhyB!

On the one hand, I'd like to update the iOS side to implement the new "loading screen" in the Gutenberg repo instead of WPiOS, in order for both the main WPiOS app and the demo app to have the loading screen.
On the other hand, re-using WPiOS' loading view helps ensure that the UBE's loading experience is (and stays) consistent with the rest of the WPiOS app.
The implementation in wordpress-mobile/WordPress-iOS#16586 favors leveraging WPiOS' existing loading view, but its downside is that it leaves the Gutenberg demo app without the new loading screen.

On a related note: As mentioned in p1624302343053500/1623681835.423800-slack-C6UJ0KRKQ, the demo app currently differs between iOS and Android with regard to the progress bar. If you run the Android demo app, the UBE shows a progress bar (thin blue line under the navigation bar) by way of a system ProgressBar component, but on the iOS demo app, it does not. This is because the UBE on iOS does not have a progress bar implemented in the demo app, but instead implements it in the WPiOS repo using the (existing) custom WebProgressView, which again has the advantage of keeping the UBE's look & feel consistent with the rest of the app. Likewise, its disadvantage is that it left the demo app without a progress bar.

(I think if WPAndroid were to change its progress bars app-wide at some point in the future, the UBE's progress bar would be difficult to update because it relies on an implementation that resides in Gutenberg instead of the main app.)

[guarani]

It seems like there's a trade-off here where some parts of the editor UI can be implemented in either the Gutenberg repo or the main apps.
Implementing in the Gutenberg repo allows us to give the demo app a fully-fledged UBE experience with all its bells and whistles (i.e. loading screens, progress bars, etc). Implementing in the main apps helps ensure the UBE stays visually in-sync with the main apps, but at the same times provides a poor UBE experience in the demo app.

[hypest]

👋 thanks for the analysis @SiobhyB and @guarani, and the ping.

The demo app is not trying to be the reference implementation and it should be fine to differ from the WP apps, including having slightly different implementation details between the platforms or no implementation at all. In other words, I wouldn't try too hard to keep the implementations exactly aligned. In our case with the progress bar, I'd try to follow the implementation already there in each platform, without spending much more effort on it. We can kick off a refactor to align if we see the need. Does that help?

[guarani]

👋 Thanks for sharing your thoughts here, @hypest! It sounds our current approach, which is differs slightly implementation-wise between Android and iOS, is the best approach for now.

@SiobhyB, if you agree, I will merge wordpress-mobile/WordPress-iOS#16586 today which will be included in the 17.7 release cut next Monday.

[SiobhyB]

@hypest, thank you for that insight, it's helpful to know that small implementation differences between the two platforms are okay. It sounds like we went with the best approach, by following the progress bar here. 🎉

@SiobhyB, if you agree, I will merge wordpress-mobile/WordPress-iOS#16586 today which will be included in the 17.7 release cut next Monday.

Sounds great to me, @guarani! I'll mark my PR chain as ready for review today too.

@hypest, would you have time to review this this week? If so, I'll request you as the reviewer when the PRs are green. :) Thanks in advance!

[hypest]

@hypest, would you have time to review this this week? If so, I'll request you as the reviewer when the PRs are green. :) Thanks in advance!

Ah, let's default to finding someone else besides me for the time being. I might be able to have a look on Thursday/Friday otherwise, thanks for checking @SiobhyB !

[SiobhyB]

Ah, let's default to finding someone else besides me for the time being. I might be able to have a look on Thursday/Friday otherwise, thanks for checking @SiobhyB !

Sure thing! @AmandaRiu, would you possibly have some time for reviewing this PR this week?

[guarani]

Sounds great to me, @guarani! I'll mark my PR chain as ready for review today too.

Awesome, thank you @SiobhyB. I've now merged the WPiOS PR.

[AmandaRiu]

Ah, let's default to finding someone else besides me for the time being. I might be able to have a look on Thursday/Friday otherwise, thanks for checking @SiobhyB !

Sure thing! @AmandaRiu, would you possibly have some time for reviewing this PR this week?

No problem, I'll take a look at it today! 👍

[AmandaRiu]

Code reviewed and works great! Tested the following scenarios and all passed:

• 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

Once the conflict is resolved, this will be ready for merge