Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RNMobile] Fix social icons block alignment #6146

Merged

Conversation

wpmobilebot
Copy link
Collaborator

@wpmobilebot wpmobilebot commented Sep 1, 2023

Related PRs

Description

This PR was generated by version-toolkit to downstream the changes for gutenberg submodule.

Additionally, this PR adds a UI test case to gutenberg-editor-sanity-test-1-visual.test to test the fix for #6133 and ensure a block outline is added for Social Link blocks added via the appender.

@peril-wordpress-mobile
Copy link

peril-wordpress-mobile bot commented Sep 1, 2023

Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job!

@derekblank derekblank self-assigned this Sep 1, 2023
@derekblank
Copy link
Contributor

@dcalhoun If you observe the updated image snapshots, you'll note that the top and bottom of the child Social Link block outline is cut off.

Screenshot 2023-09-01 at 4 12 15 pm

As the child Social Link block outline is flush with the parent Social Icon block and looks nice in the Editor itself, I believe this cut off is likely due to the way the screenshot element is being selected:

const socialLinksBlockXpath = isAndroid()
? '//android.widget.Button[@content-desc="Social Icons Block. Row 1"]'
: '(//XCUIElementTypeOther[@name="Social Icons Block. Row 1"])[1]';
const socialLinksBlock = await editorPage.driver.elementByXPath(
socialLinksBlockXpath
);

Let me know if you have any ideas of a way around this, or if you feel this might be an acceptable limitation screenshotting an element. We could always just capture the entire editorPage instead of only the Social Icon block, if that feels better from an image snapshot perspective. Another alternative would be to seek design feedback on if the child Social Link block outline margin should be smaller and "within" the boundaries of the parent Social Icon block. At the moment, this feels like an odd change to make based on the result of a UI snapshot, but seeking other perspectives.

Screen.Recording.2023-09-01.at.3.46.57.pm.mov

@derekblank
Copy link
Contributor

I wasn't able to build the UI tests for iOS to capture the iOS image snapshots, which has been discussed on a separate issue at p1693536173206879-slack-C6UJ0KRKQ. I can resume this later once that issue is resolved, but if anyone reviewing can capture iOS image snapshots and wants to update, please feel free. 🙇

Padding accommodates the borders displayed on the Social Icon buttons.
These are a result of updates in the gutenberg submodule.
Padding accommodates for borders applied to Social Icon buttons.
Copy link
Member

@dcalhoun dcalhoun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you observe the updated image snapshots, you'll note that the top and bottom of the child Social Link block outline is cut off.

My recommendation would be to retain usage of takeScreenshotByElement — it reduces the file size of snapshots and mitigates flaky tests — and leverage the padding argument it offers. This will ensure the border is fully captured in the snapshot. I went ahead and implemented this approach in f9bfdf2.

I left a few comments and commits for your review as well. Let me know what you think. 🙇🏻

@@ -331,5 +331,54 @@ describe( 'Gutenberg Editor - Test Suite 1', () => {
);
expect( screenshot ).toMatchImageSnapshot();
} );

it( 'should display the block outline of a block inserted from the appender', async () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I recognize the block outline is a highly visual element, I might argue that while its presence is important its style is not critical. I posit we could/should merely assert the functionality succeeds in the form of asserting the outline's presence in a traditional integration test. I.e. we could add a testID to the associated element and assert its presence rather than incurring the cost of an e2e visual snapshot test.

WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did consider the expense of the visual test, but I had not considered that the same behavior could be tested with an integration test asserting the presence of BlockOutline. As this current visual test addition asserts the behavior fixed in #6133, I suggest we keep the visual test and I can replace it with an integration test shortly afterward. Wydt?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. 👍🏻

@mokagio
Copy link
Contributor

mokagio commented Sep 4, 2023

@dcalhoun @derekblank I recently merged #6153 and changed the GitHub Checks. In other PRs, eg #6152, I took it upon myself to merge trunk to unblock but here there's a conflicts here, so I'll just leave it till one of you will resolve them. Happy to help if needed.

@derekblank
Copy link
Contributor

@mokagio I merged in trunk, and several of the CI tasks failed on CircleCI (example). The error seems to suggest that I needed to run npm install and commit the result, which updated the package.json in e4b87a1. Does it seem like these package.json changes be expected?

@derekblank
Copy link
Contributor

My recommendation would be to retain usage of takeScreenshotByElement — it reduces the file size of snapshots and mitigates flaky tests — and leverage the padding argument it offers. This will ensure the border is fully captured in the snapshot. I went ahead and implemented this approach in f9bfdf2.

I hadn't considered the padding argument of takeScreenshotByElement. That makes sense -- thanks for pointing it out.

Thanks for making the updates!

Copy link
Member

@dcalhoun dcalhoun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀 Thank you for writing tests.

@mokagio I merged in trunk, and several of the CI tasks failed on CircleCI (example). The error seems to suggest that I needed to run npm install and commit the result, which updated the package.json in e4b87a1. Does it seem like these package.json changes be expected?

This relates to #6159. It should be safe to merge the changes.

dcalhoun and others added 2 commits September 5, 2023 11:20
CI tasks for the previous commit resulted in errors related to a
duplicative Aztec module published for the commit SHA.
@derekblank derekblank merged commit 33c54af into trunk Sep 6, 2023
@derekblank derekblank deleted the version-toolkit/gutenberg/rnmobile/fix-social-icons-alignment branch September 6, 2023 00:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants