[RNMobile] Update Loading and Failed Screens for Unsupported Block Editor

[SiobhyB]

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

gutenberg-mobile: wordpress-mobile/gutenberg-mobile#3573
WordPress-Android: wordpress-mobile/WordPress-Android#14762
WordPress-iOS: wordpress-mobile/WordPress-iOS#16586

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 in the Android PR in this PR chain.

To account for the removal, what we do in this PR is:

• Update the in-progress layout as the UBE loads, with a message warning users that if Gutenberg is not enabled on their site, the UBE will not load.
• Show a new 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.

How has this been tested?

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.

Screenshots

UBE Progress Screen	UBE Failed Screen

Types of changes

This PR introduces a non-breaking change, with the following summarising the main changes to the code:

• The foreground_view displayed to users when the UBE is loading was fleshed out to include an image, a title, and a subtitle.
• A new showTroubleshootingInstructions() function was introduced, which fires if the UBE hasn't loaded after 10 seconds. This function updates the image, title, and subtitle displayed in the foreground_view.
• In line with the iOS change, the img_illustration_cloud_off image was taken directly from the WordPress Android app and is used in the ube_failed.xml file. The title and subtitle for the screens were also taken directly from the iOS change.

Ideas Explored

As there isn't an equivalent to the loading animation used in the iOS side of this PR, the progress screen doesn't have an image. There is, however, an existing progress bar that's animated, to convey the idea that something is happening behind the scenes.

Although I settled on no image on the progress screen, one could easily be added. Below are a couple of ones I experimented with on the Android side.

Images

UBE Progress Screen	UBE Failed Screen

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

[SiobhyB]

Marking this as ready for review as the failing tests are caused by an issue in trunk, rather than anything directly related to this PR. The tests were previously passing on this issue.

[AmandaRiu]

@SiobhyB Nice work so far! 👍 I reviewed the code and left a couple minor comments. I ran into some issues in testing. I tried to test this on WPAndroid, but when I click on the unsupported block, I get this error in the console:

Stacktrack - click to expand

 ERROR  Warning: Cannot update a component (`BlockMobileToolbar`) while rendering a different component (`SlotComponent`). To locate the bad setState() call inside `SlotComponent`, follow the stack trace as described in https://reactjs.org/link/setstate-in-render
    in SlotComponent (at slot.js:91)
    in Slot (at slot-fill/index.native.js:16)
    in Slot (at slot-fill/index.native.js:23)
    in SettingsToolbarButtonSlot (at block-mobile-toolbar/index.native.js:70)
    in RCTView (at View.js:34)
    in View (at block-mobile-toolbar/index.native.js:57)
    in BlockMobileToolbar (at with-dispatch/index.js:96)
    in WithDispatch(BlockMobileToolbar) (at with-select/index.js:57)
    in Unknown (at pure/index.tsx:43)
    in WithSelect(WithDispatch(BlockMobileToolbar)) (at block.native.js:264)
    in RCTView (at View.js:34)
    in View (at block.native.js:259)
    in RCTView (at View.js:34)
    in View (at block.native.js:213)
    in RCTView (at View.js:34)
    in View (at block.native.js:209)
    in TouchableWithoutFeedback (at block.native.js:204)
    in BlockListBlock (at with-preferred-color-scheme/index.native.js:30)
    in WithPreferredColorScheme(BlockListBlock) (at with-dispatch/index.js:96)
    in WithDispatch(WithPreferredColorScheme(BlockListBlock)) (at with-select/index.js:57)
    in Unknown (at pure/index.tsx:43)
    in WithSelect(WithDispatch(WithPreferredColorScheme(BlockListBlock))) (at block-list-item.native.js:148)
    in RCTView (at View.js:34)
    in View (at block-list-item.native.js:141)
    in RCTView (at View.js:34)
    in View (at readable-content-view/index.native.js:58)
    in RCTView (at View.js:34)
    in View (at readable-content-view/index.native.js:57)
    in ReadableContentView (at block-list-item.native.js:131)
    in BlockListItem (at with-select/index.js:57)
    in Unknown (at pure/index.tsx:43)
    in WithSelect(BlockListItem) (at block-list/index.native.js:321)
    in RCTView (at View.js:34)
    in View (at VirtualizedList.js:2015)
    in VirtualizedListCellContextProvider (at VirtualizedList.js:2030)
    in CellRenderer (at VirtualizedList.js:807)
    in RCTView (at View.js:34)
    in View (at ScrollView.js:1107)
    in RCTScrollView (at ScrollView.js:1238)
    in ScrollView (at ScrollView.js:1264)
    in ScrollView (at VirtualizedList.js:1250)
    in VirtualizedListContextProvider (at VirtualizedList.js:1080)
    in VirtualizedList (at FlatList.js:620)
    in FlatList (at keyboard-aware-flat-list/index.android.js:13)
    in RCTView (at View.js:34)
    in View (at KeyboardAvoidingView.js:220)
    in KeyboardAvoidingView (at keyboard-aware-flat-list/index.android.js:12)
    in KeyboardAwareFlatList (at block-list/index.native.js:238)
    in RCTView (at View.js:34)
    in View (at block-list/index.native.js:232)
    in BlockList (at with-preferred-color-scheme/index.native.js:30)
    in WithPreferredColorScheme(BlockList) (at with-dispatch/index.js:96)
    in WithDispatch(WithPreferredColorScheme(BlockList)) (at with-select/index.js:57)
    in Unknown (at pure/index.tsx:43)
    in WithSelect(WithDispatch(WithPreferredColorScheme(BlockList))) (at visual-editor/index.native.js:61)
    in VisualEditor (at layout/index.native.js:100)
    in RCTView (at View.js:34)
    in View (at layout/index.native.js:131)
    in RCTView (at View.js:34)
    in View (at SafeAreaView.js:41)
    in SafeAreaView (at layout/index.native.js:123)
    in RCTView (at View.js:34)
    in View (at tooltip/index.native.js:268)
    in TooltipSlot (at layout/index.native.js:122)
    in Layout (at with-preferred-color-scheme/index.native.js:30)
    in WithPreferredColorScheme(Layout) (at with-select/index.js:57)
    in Unknown (at pure/index.tsx:43)
    in WithSelect(WithPreferredColorScheme(Layout)) (at editor.native.js:167)
    in BlockEditorProvider (at with-registry-provider.js:24)
    in Unknown (at with-registry/index.js:23)
    in WithRegistryProvider(BlockEditorProvider) (at provider/index.js:108)
    in BlockContextProvider (at provider/index.js:107)
    in EntityProvider (at provider/index.js:106)
    in EntityProvider (at provider/index.js:105)
    in EditorProvider (at with-registry-provider.js:27)
    in Unknown (at with-registry/index.js:23)
    in WithRegistryProvider(EditorProvider) (at provider/index.native.js:288)
    in NativeEditorProvider (at with-dispatch/index.js:96)
    in WithDispatch(NativeEditorProvider) (at with-select/index.js:57)
    in Unknown (at pure/index.tsx:43)
    in WithSelect(WithDispatch(NativeEditorProvider)) (at editor.native.js:160)
    in SlotFillProvider (at editor.native.js:159)
    in Editor (at with-dispatch/index.js:96)
    in WithDispatch(Editor) (at with-select/index.js:57)
    in Unknown (at pure/index.tsx:43)
    in WithSelect(WithDispatch(Editor)) (at src/index.native.js:31)
    in Unknown (at renderApplication.js:47)
    in RCTView (at View.js:34)
    in View (at AppContainer.js:107)
    in RCTView (at View.js:34)
    in View (at AppContainer.js:134)
    in AppContainer (at renderApplication.js:40)

Nothing happens in the UI - no error, no feedback. I ran the demo app and pasted the test gutenberg html into initial-html.js and was able to click on it in the demo app, view the bottom sheet, and click the option to edit on the web. This allowed me to view the loading page, which looks great, but because the demo app doesn't support the unsupported block web editor that's as far as I could get. Here's a recording of the demo app testing:

[hypest]

ERROR Warning: Cannot update a component (BlockMobileToolbar) while rendering a different component (SlotComponent). To locate the bad setState() call inside SlotComponent, follow the stack trace as described in https://reactjs.org/link/setstate-in-render

Headsup that that's an error that should now be fixed (via #32506).

[SiobhyB]

@AmandaRiu, thank you for the review! I've gone ahead to fetch the latest changes from trunk to hopefully resolve the error you were seeing. I've also implemented the suggestions you've made so far. Let me know if you run into anything else I need to fix on my side.

[AmandaRiu]

@SiobhyB Thank you for updating everything. The error went away and I'm now able to test. Here are the results:

Test: TC001 - User can edit unsupported blocks on Simple WP.com sites ✅
Test: TC002 - User can discard edits to an unsupported blocks on Simple WP.com sites ✅
Test: TC003 - Editing unsupported blocks is allowed on Gutenberg-enabled Atomic sites ✅
Test: TC005 - Editing unsupported blocks is enabled on self-hosted sites accessed via Jetpack ✅

Even though I was able to edit the unsupported blocks from the above tests, I did not see any loading screen. In the gif below I'm using my testwooshop.mystagingwebsite.com site to test. This site is connected to a WPcom account created back in 4/2018. I added a UBE test post to my site via the web and then opened it in WPAndroid. I'm able to edit the post using the web editor, but I don't see the UBE loading screen:

Test: TC004 - Editing unsupported blocks is disallowed on Classic-enabled Atomic sites

I then went into my test site and installed the Classic Editor plugin and deactivated Gutenberg, relaunched the app, and tried to edit the unsupported block. Still no loading screen, and the "unable to load the block editor right now" screen is also blank:

Test: TC006 - Editing unsupported blocks is disallowed on self-hosted sites accessed via their own username and password

I created a test site using jurassic.ninja: https://outstanding-crawdad.jurassic.ninja and created a post on the web with the "Archives" block. I logged into WPAndroid using the site address/username/password option, opened the UBE post, and clicked the unsupported block. I get the "Open Jetpack Security settings" option which when clicked does open the settings even though the site doesn't have the plugin installed, and "Jetpack Settings" is not an option available on the My Site page. I can enable the WPcom login but I'll continuously be directed to "Open Jetpack security settings":

Let me know if I can help with additional testing. I can also add you to my test sites. Just let me know 👍

Tested on Pixel 4 XL emulator running Android 11.

[SiobhyB]

Huh, thanks for this @AmandaRiu, I'm not able to replicate what you're seeing, so will dig into this more next week and may take you up on your offer to access your test sites. I tried a variation of unsupported blocks and Atomic/Jetpack sites, all on an account that was created back in August 2012, but the progress and failed screens are displaying on my side.

For reference, here's what I'm seeing when accessing unsupported blocks on a classic-enabled Atomic site. The loading screen displays, eventually followed by the failed screen, as hoped for:

Screen.Recording.2021-06-26.at.00.23.38.mov

Similarly, the loading screen is displaying on a Jetpack-connected site in my testing:

Screen.Recording.2021-06-26.at.00.28.31.mov

I'll do further testing, with a fresh mind, next week.

[SiobhyB]

@AmandaRiu, I've continued testing on my main account, which was created in August 2012, as well as a test account that was created in July 2014, but I am seeing the new screens when testing the UBE on both simple and Atomic sites. I'm stumped. 🤔

I have a couple of questions to hopefully help pinpoint why the screens don't load in your testing:

• From re-reading your comment, it seems you're not seeing the new screens on any site under the account you're testing with, even simple sites, is that right?

• If you navigate to the layout/activity_gutenberg_web_view.xml file on your local set up, do you see the changes introduced with this PR? What happens if you change the background colour of the current loading screen from white to a different colour? It'd be useful to know if the changes to the layout in that file are being reflected in your testing at all.

Thanks in advance! 🙇‍♀️

[AmandaRiu]

@SiobhyB Since you unable to reproduce the issues I was having I repulled all branches and started from scratch to make sure I was getting everything and testing all the changes, and it worked! I'm not sure what was going on, but I'm now able to see the loading and error screens. 👍

The only part I'm unsure of at this point is TC006 – Editing unsupported blocks is disallowed on self-hosted sites accessed via their own username and password. I'm getting stuck in an endless "Open Jetpack Security Settings" loop while logged into a self hosted site via Site Address + username/password option:

Here are the steps to reproduce this issue:

1. On a self-hosted test site that does not have the Jetpack plugin installed, create a new post with the "Archives" block on the web.
2. Log into this self-hosted, non-jetpack-connected site on WPAndroid using the "site address" option.
3. Click "Posts" to view the list of blog posts on the site.
4. Open the post from step 1
5. Click the unsupported block to open the "unsupported block" bottom sheet. You should see the "Open Jetpack Security Settings" option.
6. Tap "open jetpack security settings" to open the settings and enable WPcom Login.
7. Tap the "back" arrow and tap the unsupported block again until the bottom sheet displays again. Notice how it still asks that you "Open Jetpack Security Settings".

The reason the Jetpack Security settings aren't working is because it can't work - Jetpack is not installed on the test site. As a sanity test, I rebuilt the WPAndroid app using the develop branch and I get a more appropriate message in the bottom sheet:

I'll invite you to my test site so you can test as well. Please let me know if you have any questions.

[SiobhyB]

Ah, great catch @AmandaRiu. 🙇‍♀️

I found the option to log in via Jetpack's SSO pops up if the unsupportedBlockEditorSwitch boolean evaluates to true here.

It began evaluating to true for all self-hosted sites, even those without Jetpack, when I removed the "gutenberg".equals(mSite.getWebEditor()) check from it in wordpress-mobile/WordPress-Android@d0f4745. This is because it was only checking for whether SSO wasn't currently enabled, which is obviously true for all self-hosted sites.

In wordpress-mobile/WordPress-Android@bef9cf8, I've added an additonal check for whether a site is actually a Jetpack site to unsupportedBlockEditorSwitch. This fixes the issue in my testing.

Let me know if this seems like a solid fix for you or if you see any room for improvement. :)

[AmandaRiu]

@SiobhyB Tested and the erroneous "Jetpack Settings" issue is resolved! Really nice work on this project! I ran through all the tests again 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