Editor help documentation images missing, content obscured

[dcalhoun]

Description

Images displayed within the editor's "Help" section display blank boxes rather than the images themselves. Additionally, after closing and re-opening the help section, content is obscured by the scroll view only populating 50% of the device height.

This appears to have begun occurring in 23.0 app release, likely related to #51303.

Step-by-step reproduction instructions

1. Open the mobile editor.
2. Tap the third-dot button in the top-right corner to open the action sheet.
3. Tap Help.
4. Navigate to any of the help topics.

Expected behaviour

The images are displayed and all text content is accessible via scrolling.

Actual behaviour

The image are missing and text content at the bottom of the page is inaccessible as it is cut off.

Screenshots or screen recording (optional)

Reproduction video

reproduction.MP4

Before	After

WordPress information

• WordPress version: 6.3
• Gutenberg version: v16.4.0
• Are all plugins except Gutenberg deactivated? Yes
• Are you using a default theme (e.g. Twenty Twenty-One)? Yes

Device information

• Device: iPhone SE
• Operating system: iOS 16.5.2
• WordPress app version: 23.0

[dcalhoun]

The cut off content occurs in the Demo editor (iOS and Android). So, possibly related to #52563, which was included in #51303.

The images correctly display when using the Demo editor (iOS and Android) and in the WordPress app for Android. So, the missing images in the WordPress app for iOS must relate to packaging the app via an XCFramework and wordpress-mobile/gutenberg-mobile#5924.

[dcalhoun]

👋🏻 @mokagio do you know if we might need to define specific XCFramework packaging steps to include the relevant static image files?

Running the npm run bundle command in gutenberg-mobile places these files into the bundle directory. Presumably the files were then "picked up" by the pre-XCFramework iOS host app integration.

[derekblank]

Do you know if we might need to define specific XCFramework packaging steps to include the relevant static image files?

I think this may be the case. According to the docs, the name of static image resources needs to be known at bundle time. When logging out the source value of these images, an integer is returned. It appears either the name of the image is not being included, or the image itself is not being packaged.

(Side note: I noticed the combined size of these images is 9.7 MB. There is likely an opportunity to use WebP in place of PNG resources here to reduce the bundle size.)

[dcalhoun]

I think this may be the case. According to the docs, the name of static image resources needs to be known at bundle time. When logging out the source value of these images, an integer is returned. It appears either the name of the image is not being included, or the image itself is not being packaged.

My understanding is that the documentation's reference to names relates to the lack of support for dynamic names. E.g. you cannot interpolate a value <Image src={`image-${id}.jpg`} />, as the interpolated value would need to be computed at runtime. I believe the return of an integer value is expected, at least from my experience logging value while running a Metro server.

I believe your last point of images "not being packaged" is likely the cause of the reported missing images. My guess is that they are not included when generating the XCFramework.

(Side note: I noticed the combined size of these images is 9.7 MB. There is likely an opportunity to use WebP in place of PNG resources here to reduce the bundle size.)

Good idea!

[dcalhoun]

@mokagio we'd like to address the reported issue in the 23.0 release before it is published to the stores, if possible. The help articles can be difficult to comprehend without the visuals communicated with the images.

I opened wordpress-mobile/gutenberg-mobile#6061 exploring how we might include the static image assets in the XCFramework. Unfortunately, the XCFramework build fails in that branch locally. Would you be willing to help me debug or identify an alternative solution? 🙇🏻

[mokagio]

@dcalhoun sorry for the late followup. Having a look now 👀

[mokagio]

Possibly related to woocommerce/WooCommerce-Shared#61 (comment) which was solved via updating the bundle call --asset-dest parameter.

[mokagio]

I'm working on wordpress-mobile/gutenberg-mobile#6067 which is promising:

[derekblank]

Looks promising indeed, thanks for working on this fix @mokagio!