fix: reset embed iframe queue consistently to preserve UI commands#27419
fix: reset embed iframe queue consistently to preserve UI commands#27419hariombalhara merged 3 commits intomainfrom
Conversation
|
Hey there and thank you for opening this pull request! 👋🏼 We require pull request titles to follow the Conventional Commits specification and it looks like your proposed title needs to be adjusted. Details: |
* test: verify UI config persists on second modal open Co-Authored-By: [email protected] <[email protected]> * fix: update iframe selection logic in getEmbedIframe function Refactor the getEmbedIframe function to improve iframe selection by using a more specific selector and ensuring the last iframe is targeted in cases of repeated modal openings. This change enhances reliability in iframe handling during tests. --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
E2E results are ready! |
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
Prompt for AI agents (all issues)
Check if these issues are valid — if so, understand the root cause of each and fix them.
<file name="packages/embeds/embed-core/playwright/lib/testUtils.ts">
<violation number="1" location="packages/embeds/embed-core/playwright/lib/testUtils.ts:90">
P2: `elementHandle()` does not wait for the iframe to exist; removing `waitFor()` can return null and exit early before the target iframe is attached. Re-introduce a wait for the locator to avoid flaky null returns when another embed has already set `iframeReady`.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| const iframeSelector = `iframe[name="cal-embed=${calNamespace}"]`; | ||
| // In case of modal we don't cleanup previous iframe on repeat click, so we should read the last one by default as that would be the one actie | ||
| const targetIframeElement = page.locator(iframeSelector).last(); | ||
| let elementHandle = await targetIframeElement.elementHandle(); |
There was a problem hiding this comment.
P2: elementHandle() does not wait for the iframe to exist; removing waitFor() can return null and exit early before the target iframe is attached. Re-introduce a wait for the locator to avoid flaky null returns when another embed has already set iframeReady.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At packages/embeds/embed-core/playwright/lib/testUtils.ts, line 90:
<comment>`elementHandle()` does not wait for the iframe to exist; removing `waitFor()` can return null and exit early before the target iframe is attached. Re-introduce a wait for the locator to avoid flaky null returns when another embed has already set `iframeReady`.</comment>
<file context>
@@ -87,14 +87,19 @@ export const getEmbedIframe = async ({
- await targetIframeElement.waitFor();
- const elementHandle = await targetIframeElement.elementHandle();
- const embedIframe = await elementHandle?.contentFrame();
+ let elementHandle = await targetIframeElement.elementHandle();
+ let embedIframe = await elementHandle?.contentFrame();
</file context>
There was a problem hiding this comment.
I reviewed the Cubic AI feedback regarding the elementHandle() call at line 90 in packages/embeds/embed-core/playwright/lib/testUtils.ts.
The confidence score for this issue is 6/10, which is below the 9/10 threshold required for automated fixes. The issue suggests re-introducing a waitFor() call before elementHandle() to avoid potential null returns.
Since the confidence is below the threshold, I'm not making changes automatically. The PR author or reviewers should evaluate whether this is a valid concern that needs to be addressed manually.
Devin AI is addressing Cubic AI's review feedbackA Devin session has been created to address the issues identified by Cubic AI. |
emrysal
left a comment
There was a problem hiding this comment.
Looks good to me, sensible change.
What does this PR do?
Fixes inconsistent queue reset behavior in the embed iframe. Previously, after processing queued actions, the queue was completely cleared (
this.iframeDoQueue = []), whileiframeReset()preserved UI-related commands. This PR extracts the queue filtering logic into a reusableresetQueue()method and uses it in both places to ensure consistent behavior.The problem: When queued actions were processed, all commands including UI configuration commands were cleared. This meant UI settings wouldn't persist correctly across certain scenarios.
The fix: Extract the queue filtering logic into
resetQueue()and call it both iniframeReset()and after processing queued actions, ensuring only commands incommandsPersistAcrossIframeResetsare preserved.Mandatory Tasks (DO NOT REMOVE)
How should this be tested?
Cal("ui", {...}))Human Review Checklist
commandsPersistAcrossIframeResetscontains the correct set of commands that should persistSummary by cubic
Make embed iframe queue reset consistent so only UI-related commands persist after reloads. This prevents stale actions and keeps UI config in sync across iframe resets.
Written for commit 9a13594. Summary will update on new commits.