Unsupported block fallback

[etoledom]

This PR implements a message to the gutenberg bridge when the user taps to open an unsupported block on a web view.

Gutenberg side PR: WordPress/gutenberg#21150
WPiOS side PR: wordpress-mobile/WordPress-iOS#13967
WPAndroid side PR: wordpress-mobile/WordPress-Android#11919

To test:

• Create a post on web with a block that is not supported on Mobile.
• Open that post on Mobile.
• Tap on the (?) button on the unsupported block.
• Choose the Edit block in web browser option.
• Check that you can edit the block in the web view that appears.
• Press Continue to save the changes.
• Save the changes to remote or check on Preview that the changes have been retrieved successfully.

We need to test these steps in:

• WPCom
• WPCom Atomic
• Self Hosted with Jetpack
• Self Hosted without Jetpack
  • v5.0
  • v5.1
  • v5.2
  • v5.3
  • latest

Note: For WP v5.0 and 5.1, the interface is not completely cleaned up. You might find extra not-needed elements. I opted to not add extra complexity to fix these cases.

[iamthomasbishop]

Hey @etoledom, I took some time last night to review progress via the test build (only on iOS) and jotted down some notes. I tried to section things off into mobile-editor specific and web-editor specific. Let me know if you have any questions or concerns!

Mobile editor

• Copy changes
  • you can also edit this post on the web ⇒ you can also edit this block using your device's web browser
  • Edit post on Web Browser ⇒ Edit block in web browser
• The action buttons in the bottom sheet should be using our primary blue color
• Would it make sense to provide the same type of path for blocks that have errors on mobile but not web? For example, I have a Heading block that has an error of “Problem displaying block” (I believe because I added a custom HTML anchor in advanced settings). It would be nice to be able to get to the web editor in the same way to fix this. It might not solve every error issue, but I imagine it’d help if you want to troubleshoot.

Web editor

• Copy changes:
  • Edit on Web ⇒ Edit [block type]
  • Save ⇒ Save changes
• [iOS] Is there any way we can use a modal sheet instead of a full-screen/width view? In this context of quick-editing a single block, it might be clearer
• Embeds are flickering on web editor
• Do we have the ability to hide more elements on the UI? Here are some examples:
  • “Document” tab of the sidebar: feels a little unnecessary in this context
  • In the ••• menu on block toolbar, some of the elements also seem odd in the context of “emergency single-block editing” — I think we could basically hide almost everything except Show block settings and Edit as HTML , although that might be a controversial opinion 😆
• Can we force the “top toolbar” setting in the web editor?
• [iOS] For the sake of consistency, can we mimic the Aztec iOS behavior of asking the user whether they want to save or discard when they tap X to exit the web editor? Even just a simple popover or dialog that says “are you sure you want to discard your changes?” would be enough.
• Would it be possible for us to provide safe areas on the web browser for devices that utilize them? This primarily comes into play on tablet, because on larger breakpoints GB shows a document navigation toolbar along the bottom edge of the screen — on iPad the safe are isn’t respected, and in return that toolbar can become cut off

[etoledom]

Thanks for the feedback @iamthomasbishop !

While I work on them, I have a few questions:

The action buttons in the bottom sheet should be using our primary blue color

Same color for dark mode?

[iOS] Is there any way we can use a modal sheet instead of a full-screen/width view?

Yes. This is what I was using before, but the user can close it by sweeping down and lose the content, so I decided to go with full screen.

We can go with the modal presentation. This is how it looks:

Can we force the “top toolbar” setting in the web editor?

Not sure what do you mean by this 🤔
One thing I did was to select the block automatically so the block toolbar is visible from the beginning. Is that right?

Would it be possible for us to provide safe areas on the web browser for devices that utilize them?

I do see that bar on Tablets when the web view is presented full screen.
In what iPad are you testing it?
If we change to modal presentation, this will not longer be visible though (smaller breakpoint).

[iamthomasbishop]

Same color for dark mode?

Good question. What I meant is we should use the main blue, which IIRC is blue 50 in light mode and blue 30 in dark mode (from color studio).

Yes. This is what I was using before, but the user can close it by sweeping down and lose the content, so I decided to go with full screen.

Isn't there a way to disable swipe-to-dismiss in these types of modals? If so, let's disable that.

Not sure what do you mean by this 🤔

What I mean is on the web (on a bigger screen), if you go to the top-level ••• menu, you see an option for Top toolbar. Example

One thing I did was to select the block automatically so the block toolbar is visible from the beginning. Is that right?

This part is fine, I just think when the block toolbar is active (when a block is selected), I'd like it to be top-aligned instead of floating (if possible — this isn't a dealbreaker).

I do see that bar on Tablets when the web view is presented full screen.
If we change to modal presentation, this will not longer be visible though (smaller breakpoint).

Ahh, that's a good point. Can ignore this point then, if that element isn't shown on that view. Although for any kind of nested block, that would be handy to have (because navigating nesting on the current web UI without it is nearly impossible).

[etoledom]

Isn't there a way to disable swipe-to-dismiss in these types of modals? If so, let's disable that.

Just found a way! 🎉

[etoledom]

Ahh, that's a good point. Can ignore this point then, if that element isn't shown on that view. Although for any kind of nested block, that would be handy to have (because navigating nesting on the current web UI without it is nearly impossible)

So I guess it is a problem to be addressed on the Web side. I know InnerBlocks navigation is a work in progress on web, so we might have some improvements for free there.

Most of the time we will be showing the smaller screen size that doesn't show this navigation option.

On iPad, using the modal presentation will solve a big problem (to hide the Page settings when no block is selected). So probably we won't have this navigation option even on iPads.

I'd like to go with the modal presentation on iPad for this reason if that's fine.

What I mean is on the web (on a bigger screen), if you go to the top-level ••• menu, you see an option for Top toolbar. Example

I tried that out before, since it looks promising. The problem is with the block toolbar imbedded inside the top toolbar, it becomes quite difficult to remove all other elements from the top toolbar.

With he current approach we remove the whole top bar by setting it's height to 0 (since the block toolbar is still a child, we can't just use display: none).

But again, using modal view, the block bar will be pinned at the top anyway as we want it to be! 🎉

Soon will push an update.

[iamthomasbishop]

@etoledom Thanks for prepping another build to test on WPiOS! I had a chance to test and most everything is looking solid — just a few bits of feedback:

Mobile editor

• It looks like the Edit block in web browser action button label got the updated blue color, but not the Dismiss one.
• Can we force the action button borders/separators to extend to the edges of the initial "XYZ block isn't yet supported" bottom sheet (16px further to the left and right)? If we don't already have a separator variation for this, it would be nice to add one (although I wouldn't consider it a blocker for this)

Web editor

• As mentioned previously, I‘d like to show a dialog to the user when they have made changes and tap the X button, because it feels unclear whether or not the changes made in the modal are applied to the main editor. We can probably re-use the content from Aztec iOS.
• Can we force the action button borders/separators to extend to the edges of the sheet (16px further to the left and right)? If we don't already have a separator variation for this, it would be nice to add one (although I wouldn't consider it a blocker for this)
• Disabling swipe-to-dismiss on the modal feels much better 👍
• I know I proposed changing the modal title to Edit [block type], but after seeing it, I think we should append the word block at the end — so it'd be Edit [block type] block (aka Edit YouTube block, etc).
• I think removing the clutter from the ••• menu on the block toolbar makes things a whole lot less cluttered. I understand that hiding things in this menu is a bit of a CSS hack, but I imagine we’ll hear feedback that we shouldn’t hide the Edit as HTML option. This is a good start though, because I would rather start w/ the most basic options and let users tell us what the most important things are to them. Honestly, I just tried only switching from visual to Edit as HTML and back on desktop, and got an error that resulted in unrecoverable content 😱 So at least users won’t be able to break their content very easily in the modal.

[etoledom]

I‘d like to show a dialog to the user when they have made changes and tap the X button

@iamthomasbishop - I'm having problems with this. Ideally we won't want to show this dialog if there are no changes, but it's getting difficult to know if there are changes.

The HTML returned by the parser is (usually) different to the one given even if there are no changes made by the user. And the flag isPostDirty from gutenberg will be true since we are modifying an empty post.

We can always show the dialog even if the user did nothing, or we can just not show it (at least for this first iteration until we figure out a better way).

Maybe we can change the x button with a Discard button to make it clear? 🤔

[guarani]

I hadn't thought of bypassing the running of the mobile app and testing directly with a site running in Docker @etoledom! (I've done that once locally and used the instructions in the Gutenberg repo).

We have to test the latest gutenberg version under development.

That would be done by using the tip of Gutenberg's master branch, correct?

Since what we want to test is just CSS overrides on Gutenberg web, what about bypassing the mobile part? Maybe we can run gutenberg web, insert the CSS and make screenshots directly?

I agree, we would ideally do it on a browser sized for mobile to make sure the experience is similiar to what our web view gets.

Talking with @hypest , he mentioned about starting with even simpler tests. Something that could check for the existence of the CSS classes we are interested in. I'm not sure if this is actually simpler or how effective might it be, but it's another option to start with.

Yes, I think that would be perfect for an initial iteration. Then a second iteration could include the visual snapshot tests that would allow us to catch new UI elements or other changes in the editor UI.

---

In summary, what I understand is the current plan is to:

1. Simple Appium tests to insert an unsupported block on either platform and ensure the web view modal can be opened
2. A first iteration test with a Docker instance of WordPress (i.e. self-hosted) with the latest Gutenberg version to test for the presence of the CSS classes we depend on
3. A second iteration test again with the same Docker instance, this time to test visual changes

This covers self-hosted WordPress, but I'm not sure if we need to cover other cases like .com – or if they're they'll be identical. Also, I considered whether we can further "short-circuit" point (2) above to check for the CSS classes directly in the code-base without spinning up an entire WordPress instance in Docker, but that wouldn't be a reliable indicator of whether they're present in the actual running webpage.

[guarani]

Tests on iOS build #29262

Overall, things are working very well – except for one authentication issue. I found that under certain conditions I'm asked to log in again upon opening the unsupported block editor. This seems to occur only when using a site that is not hosted on a wordpress.com domain (note, Atomic sites are also affected).

The authentication issue

On opening the unsupported block editor using any non WordPress.com site (for example Atomic/Jetpack/self-hosted), I'm asked to log in again (reproduced consistently). I think the trick to reproducing this bug is to make sure you don't open the unsupported block editor from a .com site first – just go straight to a post on one of these affected platforms after doing a fresh install of the app.
It appears that opening the editor on a .com site caches authentication credentials which are then used when I then open a different type of site.

Atomic Site	Self-hosted with Jetpack

Scenarios tested

• WPCom
• WPCom Atomic
• Self Hosted with Jetpack
• Self Hosted without Jetpack

Scenarios not tested

• I haven't yet tested different WordPress versions we cover: v5.0, v5.1, v5.2, v5.3
• Since authentication issues appear to be domain related, I also want to test WordPress.com sites that are mapped to a custom domain (non-*.wordpress.com).

What's working great 🎉

• The editing experience feels close to being ready for launch
• I could edit blocks without a hitch (I used Audio and Twitter blocks for tests)
• Love how dark mode works seamlessly in the web view
• The progress indicator looks great

What needs attention ⚠️

• There's an authentication issue I'll explain below on non .COM sites
• The keyboard Done button (just above the keyboard) has really low contrast (white text on a grey background) – not sure if we can apply a tint to it specifically

Outstanding issues

A couple of things I think we haven't made a decision on:

• Are we going to leave as-is the title for the action button in the bottom sheet? It's "Edit block in web browser" which could work, but I found a little confusing from a user's point of view
• We don't have pretty names for some blocks, but that appears to be outside our control – can we ship in the current state?

A minor detail I noticed:

• When deleting an unsupported block, the bottom sheet says "Remove Unsupported" – this is actually not part of this project as such but may be worth adjusting.

---

See overview of tests performed

WordPress.com

• I was able to edit an unsupported block successfully ✅.

Atomic Site

Site: https://pschrottkyatomicsite1.blog/

• On opening the web view using an Atomic site, I'm asked to log in again (reproduced 3/3).
• Once logged in I tested with an Audio block and I was able to edit the block successfully ✅.

Self Hosted with Jetpack

Site: https://agreed-green.jurassic.ninja

• Here I had the same problem where the web view would ask me to login. The difference here is that trying with a .com site first and then switching to this Jurassic Ninja site didn't fix the issue. Maybe cookies aren't being persisted because they're different domains (i.e. wordpress.com vs jurassic.ninja).
• I was able to edit an unsupported block successfully ✅.

Self Hosted without Jetpack

Site: https://nuclear-smelt.jurassic.ninja

• The same login issue is present when opening the web view, but what's telling here is that if I had previously logged in to the previous site (https://agreed-green.jurassic.ninja), I didn't have the issue. This reaffirms the idea that authentication is being cached on a per domain basis.
• Editing a block worked fine ✅.

cc @etoledom

[marecar3]

Hey @etoledom @guarani 👋

I can confirm that we have same problem with WPiOS and WPAndroid when user tries to open the atomic site but in a case that he didn't visit any other site (cookies should be cleared) . Here is the video.

[guarani]

I can confirm that we have same problem with WPiOS and WPAndroid when user tries to open the atomic site but in a case that he didn't visit any other site (cookies should be cleared) . Here is the video.

@marecar3 thanks for the heads-up! I tested the Android build today while keeping this issue in mind.

---

Tests on Android build #53473

Similar to the iOS tests above, the experience overall was great – the known authentication issue is the only major issue I came across. Below I also cover some minor details I came across which I haven't seen mentioned before.

Scenarios tested

WPCom, WPCom Atomic, Self Hosted with Jetpack, Self Hosted without Jetpack

Scenarios not tested

• I haven't yet tested older WordPress versions: v5.0, v5.1, v5.2, v5.3
• Since authentication issues appear to be domain related, I also want to test WordPress.com sites with custom domains

What's working great 🎉

• Like on iOS, this feels very close to finished (except for the known auth issue)
• Dark mode
• Tested working well on tablets

What needs attention ⚠️

• The progress indicators on iOS is darker and the one on iOS is lighter – not sure if this is expected as I've seen some color differences between the platforms.

See comparison 📷

iOS	Android

• On a fresh install, after completing the second login (due to the auth issue) on an Atomic site, I got presented with the what looks like wp-admin – @marecar3 I'm not sure if this is a separate issue or part of the authentication issue. This blocked me from finishing tests on Atomic sites.

See screen recording 📹

Atomic site issue

• A header bar appears for a few seconds while the editor loads on a self-hosted site with Jetpack enabled

See screen recording 📹

Flashing header

[iamthomasbishop]

The progress indicators on iOS is darker and the one on iOS is lighter – not sure if this is expected as I've seen some color differences between the platforms.

@guarani that's interesting, good catch! I'm not sure where this is coming from, but I don't think we've explicitly changed anything WRT the progress bar (@etoledom @marecar3 is that correct?). Assuming it's not something we changed, we prob don't need to worry about it too much as part of this particular work, but we could create a ticket/proposal to align the platforms.

[etoledom]

Hey @etoledom @guarani 👋

I can confirm that we have same problem with WPiOS and WPAndroid when user tries to open the atomic site but in a case that he didn't visit any other site (cookies should be cleared) . Here is the video.

Here’s what I have found so far:

• There’s an endpoint for Atomic sites to retrieve the cookies /atomic-auth-proxy/read-access-cookies.
• The request to this endpoint is always returning a 500 error.
• When I try another site (say a Premium one), it will work, and going back to Atomic it will now work as expected too (but the request is still fired and still returning 500).
• For private Atomic sites the endpoint works as expected returning the cookie 🍪, but still auth doesn’t work (I think the cookie is not stored properly, but didn’t have time to investigate this more deeply).
• Since public Atomic sites return 500, I tested setting the authenticator as .regular (instead of .atomic) for these sites and this does work 🤔

I talked with @aerych (since he helped setting this up) and we agreed on preparing a PR to check this out.

This would be pretty much to add a check if the site is also private here:

https://github.com/wordpress-mobile/WordPress-iOS/blob/f804f6fd22ba563b1a6ba4676eab04a7e7dce42c/WordPress/Classes/Utility/Networking/RequestAuthenticator.swift#L49

And to try to figure out why private atomic doesn’t work, even when we get the cookie.

I think it would be good to know if it’s expected for this endpoint to return 500 for public atomic sites too.

@khaykov also might help us since (afaiu) he implemented these Android side of it.
@marecar3 this problem might also be what’s happening on Android

cc @guarani

[guarani]

I'm not sure what PreviewsEnabled does here in workspace settings cc @etoledom

[cameronvoell]

Verified not showing up with the DEV flag = false. Excited to keep using this as we fix the final issues and get it ready to ship, such a cool feature! 🎉

[guarani]

Tests

On both iOS and Android

1. ✅ Option for editing unsupported blocks appears on development builds
   Run yarn start:reset in one window and yarn ios in another
2. ✅ Option for editing unsupported blocks does not appears on release builds