fix: typo in viewport dropdown

[FireNdIce3]

• Closes Typo in viewport menu #23632

User facing changelog

Additional details

Steps to test

How has the user experience changed?

PR Tasks

• Have tests been added/updated?
• Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
• [N/A] Has a PR for user-facing changes been opened in cypress-documentation?
• [N/A] Have API changes been updated in the type definitions?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[CLAassistant]

All committers have signed the CLA.

[emilyrohrbough]

@FireNdIce3 Thank you for opening a PR to fix this issue! Looking at where this translation is used, it looks liek it should be populating with the user's configuraiton file name or with cy.viewport(): https://github.com/cypress-io/cypress/blob/develop/packages/app/src/runner/SpecRunnerHeaderOpenMode.vue#L109

Could you see if updating to the following correctly populates this translation?

Suggested change

	"configText": "Additionally, you can override this value in your cypress.config or via the command npx cypress something."
	"configText": "Additionally, you can override this value in your {0} or via the {1} command."

If it does, can we ensure this test is passing? https://github.com/cypress-io/cypress/blob/develop/packages/app/src/runner/SpecRunnerHeaderOpenMode.cy.tsx#L184

[FireNdIce3]

I have made the changes. I guess it should work fine, here is my commit Id 4b09dc3

[chrisbreiding]

Looks good!

Could you add a test for this? I think adding assertions to this test and this test should suffice.

[pratiqdev]

** Ignore this comment! **
commit 4b09dc3 solves the issue.

---

I was unable to resolve the issue locally so I have not created a PR. I took some notes while testing / exploring and I will include them here.

Files

1. packages/frontend-shared/src/locales/en-US.json
2. packages/app/src/runner/SpecRunnerHeaderOpenMode.vue
3. packages/app/src/runner/SpecRunnerHeaderOpenMode.cy.tsx
4. packages/app/cypress/e2e/cypress-in-cypress-e2e.cy.ts

---

Origin

The issue seems to originate within the function responsible for
parsing and replacing in-string placeholder values with real values.
This text has string-vars like: in string var like {this} replaced.

The original (unreplaced) text segment exists in a locale source (file-1)
at runner.viewportTooltip.configText

The adjacent entry of runner.viewportTooltip.infoText has its
placeholder values correctly replaced at {0}, {1} and {2}

---

The locale object values are passed to an <i18n-t> component as the
keypath prop in (file-2)

<i18n-t
  tag="p"
  keypath="runner.viewportTooltip.configText"
  class="mb-24px"
>

The test file (file-3) contains a test at line 196 that checks for the
existence and visibility of the correctly replaced string:

cy.contains('Additionally, you can override this value in your cypress.config.js or via the cy.viewport() command.')
                                                               ^^^^^^^^^^^^^^^^^            ^^^^^^^^^^^^^
.should('be.visible')

There is also an example cypress test in (file-4) that tests for the
adjacent config text runner.viewportTooltip.infoText but, does not
test for runner.viewportTooltip.configText

[chrisbreiding]

@FireNdIce3 Do you think you'll be able to add a test for this?

[emilyrohrbough]

@chrisbreiding Interestingly our Component tests for this are now failing with this fixed behavior which was testing it originally https://app.circleci.com/pipelines/github/cypress-io/cypress/43400/workflows/3eb83d3f-5f15-496c-a78c-d9e62e697373/jobs/1811601

• https://github.com/cypress-io/cypress/blob/develop/packages/app/src/runner/SpecRunnerHeaderOpenMode.cy.tsx#L184
• https://github.com/cypress-io/cypress/blob/develop/packages/app/src/runner/SpecRunnerHeaderOpenMode.cy.tsx#L207

Wonder why these are inconsistent 🤔

[chrisbreiding]

Interestingly our Component tests for this are now failing with this fixed behavior which was testing it originally app.circleci.com/pipelines/github/cypress-io/cypress/43400/workflows/3eb83d3f-5f15-496c-a78c-d9e62e697373/jobs/1811601

[develop/packages/app/src/runner/SpecRunnerHeaderOpenMode.cy.tsx#L184](https://github.com/cypress-io/cypress/blob/develop/packages/app/src/runner/SpecRunnerHeaderOpenMode.cy.tsx?rgh-link-date=2022-09-20T18%3A31%3A16Z#L184)
[develop/packages/app/src/runner/SpecRunnerHeaderOpenMode.cy.tsx#L207](https://github.com/cypress-io/cypress/blob/develop/packages/app/src/runner/SpecRunnerHeaderOpenMode.cy.tsx?rgh-link-date=2022-09-20T18%3A31%3A16Z#L207)

Wonder why these are inconsistent 🤔

@emilyrohrbough Took a little digging, but I figured this out and figured out the root cause of the original bug.

The <i18n-t> component can do string interpolation in two ways. The way we were using it (and still using it in other places) relied on list interpolation, where {0}, {1}, etc rely on the order and placement of the children nested within the <i18n-t> component.

The original code looks like this (with children indexes noted):

    <i18n-t ...>
0:    <!-- disable rule to prevent trailing space from being added to <InlineCodeFragment/> -->
1:    <!-- eslint-disable-next-line vue/singleline-html-element-content-newline -->
2:    <InlineCodeFragment class="font-medium text-xs leading-5">{{ props.gql.configFile }}</InlineCodeFragment>
3:    <!-- eslint-disable-next-line vue/singleline-html-element-content-newline -->
4:    <InlineCodeFragment class="font-medium text-xs leading-5">cy.viewport()</InlineCodeFragment>
    </i18n-t>

So we used the interpolated values {2} and {4}. This works locally, in development, and in CI.

However, I'm guessing that when we build for production and produce the binary, the comments are stripped out before it does the i18n replacement, so the Vue markup ends up looking like this:

    <i18n-t ...>
0:    <InlineCodeFragment class="font-medium text-xs leading-5">{{ props.gql.configFile }}</InlineCodeFragment>
1:    <InlineCodeFragment class="font-medium text-xs leading-5">cy.viewport()</InlineCodeFragment>
    </i18n-t>

So then the interpolated values should be {0} and {1}. {2} and {4} don't even exist, so it ends up putting in empty strings (it would be nice if the build failed in that case, eh?). That's why the component tests used to pass but failed when using {0} and {1}. But {0} and {1} would have worked in the production app.

To resolve this, I changed the markup to use the other string interpolation method, slots syntax. It ensures the same values are interpolated regardless of child order or the presence/lack-of-presence of comments.

[emilyrohrbough]

@chrisbreiding whoa....nice find! I bet you are correct that prod mode was stripping these out.

[ZachJW34]

Learned something new! I do like the template connections. LGTM!