Skip to content

test: handle "Cookie Preferences and Opt-Out Rights" modal#1276

Merged
rsoaresd merged 1 commit intocodeready-toolchain:masterfrom
rsoaresd:handle_cookies_modal
Apr 30, 2026
Merged

test: handle "Cookie Preferences and Opt-Out Rights" modal#1276
rsoaresd merged 1 commit intocodeready-toolchain:masterfrom
rsoaresd:handle_cookies_modal

Conversation

@rsoaresd
Copy link
Copy Markdown
Contributor

@rsoaresd rsoaresd commented Apr 29, 2026

The "Cookie Preferences and Opt-Out Rights Your Choices About Cookies on this Site" modal appears depending on the country/state (for example, it appears for us texas), which breaks the current Developer Sandbox E2E tests against prod (pls, check this example). So, we should handle it.

Issue ticket number and link

SANDBOX-1630

image

Assisted-by: Cursor

Summary by CodeRabbit

  • Bug Fixes
    • Enhanced cookie consent handling to support multiple modal variants, ensuring consistent functionality across different consent dialog implementations.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 29, 2026

Walkthrough

Modified the handleCookiesConsent function to handle multiple TrustArc cookie-consent modal variants. The function now attempts to click "Agree and proceed with" button first, then falls back to clicking "Accept default" if the first option is unavailable.

Changes

Cohort / File(s) Summary
Cookie Consent Handling
testsupport/devsandbox-dashboard/setup.go
Updated handleCookiesConsent to support multiple TrustArc modal variants with conditional button click logic—tries "Agree and proceed with" first, then falls back to "Accept default".

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested labels

test

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately reflects the main change: adding support for the 'Cookie Preferences and Opt-Out Rights' modal that was causing test failures.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Review rate limit: 9/10 reviews remaining, refill in 6 minutes.

Comment @coderabbitai help to get the list of available commands and usage tips.

@sonarqubecloud
Copy link
Copy Markdown

@rsoaresd rsoaresd changed the title handle "Cookie Preferences and Opt-Out Rights" modal test: handle "Cookie Preferences and Opt-Out Rights" modal Apr 29, 2026
@coderabbitai coderabbitai Bot added the test Work that adds, fixes, or maintains automated tests or coverage (unit, integration, e2e, flakiness) label Apr 29, 2026
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@testsupport/devsandbox-dashboard/setup.go`:
- Around line 134-146: The OR locator is non-deterministic and can throw a
strict-mode error if both buttons exist; replace consentButton :=
agreeProceed.Or(acceptDefault).Click() with an explicit try-then-fallback: first
attempt agreeProceed.Click(), if that returns an error (or a
strict-mode/multiple-matches error), then attempt acceptDefault.Click(), and
assert no error for whichever click succeeds (use require.NoError on each
attempted click). Use the existing agreeProceed, acceptDefault, contentFrame and
require.NoError symbols to locate and implement the change.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 4ceaeeae-417e-489e-bbfb-9ad07eae41a7

📥 Commits

Reviewing files that changed from the base of the PR and between 86a74db and 95b26bf.

📒 Files selected for processing (1)
  • testsupport/devsandbox-dashboard/setup.go
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: govulncheck
  • GitHub Check: Build & push operator bundles & dashboard image for e2e tests
🧰 Additional context used
📓 Path-based instructions (1)
**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

  • testsupport/devsandbox-dashboard/setup.go

Comment on lines +134 to 146
// TrustArc can show different modals (e.g. full consent vs. simplified); accept whichever button is present.
agreeProceed := contentFrame.GetByRole("button", playwright.FrameLocatorGetByRoleOptions{
Name: "Agree and proceed with",
})

err = agreeButton.Click()
// to some us states, like texas, it appears the "Cookie Preferences and Opt-Out Rights" modal
acceptDefault := contentFrame.GetByRole("button", playwright.FrameLocatorGetByRoleOptions{
Name: "Accept default",
})
consentButton := agreeProceed.Or(acceptDefault)

err = consentButton.Click()
require.NoError(t, err)
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 29, 2026

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

In Playwright (especially playwright-go), if Locator.Or(otherLocator) matches two elements, can Locator.Click() fail due to strict mode? What is the recommended pattern to try locator A first and fall back to locator B?

💡 Result:

Yes. In Playwright, locators are strict: if you call Locator.click (including in playwright-go) and that locator resolves to more than one element, Playwright can throw a “strict mode violation”. Using locator.or (or Locator.Or in playwright-go) creates a locator that matches one or both alternatives; if both alternatives are present at the same time, the combined locator may match multiple elements and then click will fail due to strictness. Recommended pattern (try A, fall back to B): avoid calling click on an OR-locator that may match multiple elements. Instead, explicitly choose which one to click by checking visibility (or count) on each alternative and then clicking the single matching locator. Example (Node/Playwright JS pattern, same idea applies to playwright-go): const a = page.getByRole('button', { name: 'A' }); const b = page.getByRole('button', { name: 'B' }); if (await a.isVisible) await a.click; else await b.click; If you specifically use an OR locator, Playwright’s own docs show using .first to prevent the strict mode issue when the OR matches multiple elements, but they caution that .first is not recommended because page changes can make it click an unintended element. Example with OR: await expect(a.or(b).first).toBeVisible; // then decide/click based on which one is visible, as shown in the docs.

Citations:


🏁 Script executed:

#!/bin/bash
# Verify the code snippet exists at the specified lines
if [ -f "testsupport/devsandbox-dashboard/setup.go" ]; then
  sed -n '130,150p' testsupport/devsandbox-dashboard/setup.go | cat -n
else
  echo "File not found"
fi

Repository: codeready-toolchain/toolchain-e2e

Length of output: 1065


Make consent-button fallback deterministic to avoid flaky modal handling.

The agreeProceed.Or(acceptDefault).Click() pattern at line 145 can fail in strict mode if both buttons are present simultaneously, causing test flakiness. Playwright does not guarantee which locator in an OR combination is clicked, and when multiple elements match, Click() throws a strict mode violation. Use explicit try-then-fallback instead.

🔧 Proposed fix
-	consentButton := agreeProceed.Or(acceptDefault)
-
-	err = consentButton.Click()
+	err = agreeProceed.Click(playwright.LocatorClickOptions{
+		Timeout: playwright.Float(2000),
+	})
+	if err != nil {
+		err = acceptDefault.Click(playwright.LocatorClickOptions{
+			Timeout: playwright.Float(2000),
+		})
+	}
 	require.NoError(t, err)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@testsupport/devsandbox-dashboard/setup.go` around lines 134 - 146, The OR
locator is non-deterministic and can throw a strict-mode error if both buttons
exist; replace consentButton := agreeProceed.Or(acceptDefault).Click() with an
explicit try-then-fallback: first attempt agreeProceed.Click(), if that returns
an error (or a strict-mode/multiple-matches error), then attempt
acceptDefault.Click(), and assert no error for whichever click succeeds (use
require.NoError on each attempted click). Use the existing agreeProceed,
acceptDefault, contentFrame and require.NoError symbols to locate and implement
the change.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

As far as I know, either appears one or another

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

@rsoaresd, that's a good clarification — if the two TrustArc modal variants are mutually exclusive (only one appears at a time, never both), then the .Or() locator will always resolve to exactly one element, and the strict mode concern doesn't apply. The current code is safe as-is. Thanks for the context!


📝 Learnings were identified and not saved (knowledge base disabled). Enable

Copy link
Copy Markdown
Contributor

@MikelAlejoBR MikelAlejoBR left a comment

Choose a reason for hiding this comment

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

LGTM!

Copy link
Copy Markdown
Contributor

@mfrancisc mfrancisc left a comment

Choose a reason for hiding this comment

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

Thanks !

@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented Apr 29, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexeykazakov, metlos, mfrancisc, MikelAlejoBR, rsoaresd

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:
  • OWNERS [alexeykazakov,metlos,mfrancisc,rsoaresd]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@rsoaresd rsoaresd merged commit e20ac71 into codeready-toolchain:master Apr 30, 2026
8 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved test Work that adds, fixes, or maintains automated tests or coverage (unit, integration, e2e, flakiness)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants