Help behavior button in Unsupported Block Editor doesn't work on iOS, loses edits on Android

[twstokes]

Describe the bug

On iOS:

• Tapping the Help button (question mark icon at the bottom right) while editing an unsupported block does nothing
• Long pressing the Help button shows a WordPress.com login

On Android:

• Tapping the Help button shows "Confirm Navigation" with options to "Stay on this page" or "Leave this page". When choosing "Leave this page", any changes to the unsupported block are lost.
• Long pressing does nothing

To Reproduce

On a Simple site:

1. Using a web browser, add a block that's not supported by Gutenberg Mobile (currently the Markdown block will work).
2. Save the draft or publish the post.
3. Load the post in the Gutenberg Mobile editor on WPiOS or WPAndroid.
4. Choose the option to "Edit using web editor" on the unsupported block.

Expected behavior

• Tapping the Help button shows the user some form of support (or the Help button is removed)
• Long pressing the Help button does nothing

On web a new window is created and the authenticated session is loaded using existing cookies.

A few thoughts:

• The user could be navigated to an entirely new web view independently of the UBE, or jump to their OS' browser (where they'll probably have to re-authenticate)
• The button could be removed to encourage using support within the app
• The button's action could be changed to show the app's native support view

Screenshots

Smartphone (please complete the following information):

• Device: iPhone 12, Pixel 4a
• OS: iOS 15, Android 11
• Version 1.67.0

[hypest]

Ouch, the help button seems new and the UBE flow doesn't cater for it yet :(

• The user could be navigated to an entirely new web view independently of the UBE, or jump to their OS' browser (where they'll probably have to re-authenticate)
• The button could be removed to encourage using support within the app
• The button's action could be changed to show the app's native support view

I'd consider the second option as a stopgap solution. Then, some form of the third option.

[SiobhyB]

I've got a PR up to hide the button in WordPress/gutenberg#37221 and have requested you as a reviewer, @twstokes. Let me know if anything's unclear on it! :)

I was curious about the class name associated with the button, a8c-faux-inline-help, and found some background in Automattic/jetpack#18960 and Automattic/jetpack#18885. From what I've read, it seems the plan is to refactor the code around the button in the future. @getdave, can you let me know if that understanding is right? If so, maybe it'd be best to wait until the refactor before we begin any work on forwarding it to the app's built-in support?

[getdave]

@SiobhyB I'm slightly confused as this inline help work was completed as part of my work for WordPress.com. AFAIK it isn't directly connected to Gutenberg.

As far as I remember the "faux" is denoting that the element is not the true Inline Help but rather simply an anchor which links back to WP.com "Calypso" where the true inline help module can be displayed.

I believe the "faux" version of the button is intended to be replaced with the real inline help in the future but that will require some more work on WP.com to achieve this.

If you need help reaching out to anyone at A8c on those teams please let me know.

[SiobhyB]

Just noting for posterity that @getdave and I talked "off GitHub" to share how the UBE worked (and therefore why the help button could be seen within it). He helpfully clarified again that the eventual plan is to replace the "faux" help button, so hiding it, therefore, seems like the best solution for our needs for now.