🐛🧑‍💻 - PR review confuses Compose width with requiredWidth suggested modifier order removes width cap #720

Is there an existing issue for this?

• I have searched the existing issues. repo:vypdev/copilot is:issue "Compose" "width" returned no matches on 2026-10-26.

Which actions are affected?

Pull Request

Which platforms are affected?

macOS (consumer reproduction); review semantics concern shared Compose code.

Description

Copilot published a high-confidence correctness finding that confuses Compose Modifier.width with Modifier.requiredWidth. The current production form respects narrow incoming constraints. Applying the exact suggested fix instead removes the intended maximum width on a wide viewport.

Consumer: vypdev/vaultstadio#81

Finding: vypdev/vaultstadio#81 (comment)

Reviewed head: cdd8ac3f5f3793a859974c3c0945c7b0f239dce6.

Path: frontend/feature/auth/src/main/kotlin/com/vaultstadio/app/feature/auth/AuthScreen.kt:36.

Finding title: Authentication card exceeds narrow screen width. Severity low, correctness, confidence94%.

The finding says the fixed width overrides the parent's constraints and clips controls on devices narrower than400dp. That premise is incorrect for width: incoming constraints still apply. The official current API explicitly distinguishes preferred width from requiredWidth:
https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/width.modifier
https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/widthIn.modifier

Expected: validate the actual measurement semantics before publishing the finding; retain working production code when the alleged defect is disproven. Suggestions must preserve both narrow responsiveness and the wide-screen cap.

Actual: an open changes-requested finding was published. Its exact suggestion puts fillMaxWidth before widthIn; the former sends an exact wide constraint, so the latter cannot reduce it.

Reproducing the issue

Toolchain: Compose1.13.0-beta01, Kotlin2.4.20, JBR21.0.11 on Apple Silicon macOS; actual shared production AuthScreen rendered by Compose desktop tests. This is not Android/iOS device execution, nor a claim about all responsive behavior.

The unchanged production structure is:

Box(modifier = modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
    Card(modifier = Modifier.width(400.dp).padding(16.dp)) {
        Column(modifier = Modifier.padding(24.dp)) {
            // Actual production login/registration fields and buttons.
        }
    }
}

The regression AuthResponsiveInteractionTest mounts the real AuthScreen in a parent whose actual measured width is asserted. It checks unclipped horizontal bounds of every rendered field, submit action and mode switch, a positive usable width, and a bounded form on large viewports. It edits and clears the actual email field, asserts the production model receives Unicode, then invokes the actual blank-submit validation without network authentication. Fake use cases throw if unexpectedly called.

Matrix: login and registration at280/320/360/400/800dp with fontScale1, plus320dp at fontScale1.5: 12 cases.

Run from frontend/ with JBR21:

./gradlew :composeApp:desktopTest --tests 'com.vaultstadio.app.accessibility.AuthResponsiveInteractionTest' --rerun

Results and negative controls, applied sequentially to the same real production file and restored byte-for-byte after each completed Gradle invocation:

Representative measured failures:

requiredWidth /280dp:
Control overflows left: DpRect(left=-20.0.dp, right=300.0.dp)
outside DpRect(left=0.0.dp, right=280.0.dp)

suggested order /800dp:
Wide viewport must retain a bounded form:
DpRect(left=40.0.dp, right=760.0.dp) //720dp-wide control

Padding means requiredWidth does not make the inner controls overflow at every width below400dp; the measured failure is at280dp. We do not inflate the failing-case count. The existing correct production file SHA256 is f0366e669fae501672f974333418567cdaf3e22d0027b95cd07fad6677456ecc, restored after both controls. No production fix to this width is proposed.

The regression is prepared in consumer commit 9c4ff42d28657c1b5e339278a7886a74fbc74185 for the existing PR81. The full restored root desktop selection has also completed:1,315 tests, zero failures/errors/skips, with packaging, coverage gates, auth Detekt and desktop-test ktlint passing. All154 packaged production JAR hashes match the retained GUI-verified package. The commit is prepared for normal publication on the existing Action-owned branch; the12-case positive and both negative XML results are retained. Only sanitized evidence is included here.

copilot Version

3.10.5, vypdev/copilot@v3 resolved to 39679e26a22b40a5a4a40e8f167f46273157182e; CodexCLI0.164.0; reviewer/findings model gpt-6-luna.

Relevant Log Output

Run: https://github.com/vypdev/vaultstadio/actions/runs/40300565322
Job: https://github.com/vypdev/vaultstadio/actions/runs/40300565322/job/121497114566

LoadBugbotContext: selection=event, coverage=complete,
existing findings=0, retained previous findings=0,
diff files=142, diff partitions=7.
reviewId=vypdev:vaultstadio:pr-81:cdd8ac3f5f37
candidateFindings=1; publishedFindings=1; open=1; outcome=completed
finding_fingerprint=fp-c81425dc
finding_semantic=sf-7b5a1173

Native review5649952121 and comment4375779953. This is a semantic false positive in this finding, not evidence of stale context or of an incorrect deterministic state projection.

Additional context and comments

Please own the upstream investigation/fix. Suggested regression fixtures: preferred width under narrower constraints; truly overflowing requiredWidth; both orders of widthIn/fillMaxWidth on wide constraints; a bounded real form with padding. Validate framework-specific premises and candidate suggestions rather than globally suppressing width findings. A real requiredWidth overflow must remain reportable.

The consumer keeps Copilot, its generated guidance/workflows, branch protections and runtime-setup activation unchanged. We are adding the narrow production regression and counterevidence through normal PR work, not weakening the review gate or changing this correct production layout to appease a false positive.