aia-website/www/reports/phase-9-form-a-iframe-sizing-2026-10-25.md

Phase 9 — Form A iframe sizing refinement

Initial calibration: 2026-10-25 UTC Latest calibration: 2026-10-26 UTC

Scope: isolated-test Form A presentation only; no Jotform configuration, submission, or production activation.

2026-10-26 route addendum: /lp/early-intervention now uses the same fixed landing context and height profile as the four campaign landing routes. The adapter remains unavailable outside the explicit isolated-test gate.

Corrected presentation

The single fixed iframe height caused two opposite problems in the real Firefox review: the contact context could clip the message field and native Submit button, while the compact landing context retained unnecessary space after Submit.

The original pre-Builder-CSS fixed-height allowances were:

Context	Routes	768px and 1440px	320px and 390px
contact	/contact, /es/contact	75rem / 1200px	84rem / 1344px
landing	Five approved /lp landing routes, including /lp/early-intervention	42rem / 672px	50rem / 800px

After the current full-width Builder CSS was installed, the adapter was initially reduced at every approved placement:

Context	Routes	768px and 1440px	320px and 390px
contact	/contact, /es/contact	56rem / 896px	60rem / 960px
landing	Four approved /lp/aba-* routes	36rem / 576px	44rem / 704px

An October 26 desktop report then identified a Jotform required-field blur error creating an internal scrollbar on /lp/aba-therapy. The final fixed-height calibration adds bounded error-room to every Form A context:

Context	Routes	768px and 1440px	320px and 390px
contact	/contact, /es/contact	60rem / 960px	68rem / 1088px
landing	Four approved /lp/aba-* routes	42rem / 672px	50rem / 800px

The contact allowance retains fixed room for its textarea, Spanish wrapping, conditional email state, required-field messages, keyboard focus rings, and native Submit control. The compact landing allowance applies only to the four contact fields and one validation message. The hosted fallback, fixed URL parameters, isolated-test gates, no-referrer policy, and allow-forms allow-scripts allow-same-origin sandbox are unchanged.

No cross-origin automatic resize mechanism was added. Reliable dynamic height synchronization would require a reviewed Jotform helper or postMessage contract, with its external-resource, origin-validation, privacy, and accessibility implications. That remains a separate decision.

Automated verification

Check	Result
npm run check	0 diagnostics
Focused Form A/preview/nonproduction tests	14 passed
Guarded Chromium sizing test	35 checks passed: seven routes at 320px, 390px, 768px, and 1440px, plus seven no-JavaScript checks
Normal staging artifact verification	128 HTML pages; all noindex,nofollow; empty sitemap; zero hreflang; no Form A iframe or identifier
Campaign and artifact tests after normal-build restoration	18 passed

The guarded test aborts all external requests. It verified the calculated dimensions, fixed route/locale/context URLs, iframe attributes, no parent native form, no page-level horizontal overflow, the four campaign surfaces, and the Early Intervention embedded card.

Read-only real-iframe probe

tools/jotform-form-a-real-iframe-sizing.mjs requires both explicit environment approvals before it permits a request:

FORM_A_IFRAME_REAL_LOAD_APPROVED=true
FORM_A_IFRAME_JOTFORM_ASSETS_APPROVED=true

It never fills, focuses, clicks, or submits a Jotform control. It permits only read requests to https://form.jotform.com and the observed Jotform asset origin https://cdn.jotfor.ms; it blocks WebSockets, downloads, all non-read methods, and every other external origin.

The 2026-10-25 run captured 24 full-page screenshots in:

/tmp/aia-form-a-real-iframe-sizing-skBmLf

It observed 504 allowed Jotform GET/HEAD requests and blocked 40 requests to https://unpkg.com and https://events.jotform.com. No AIA production API, Google analytics/advertising, conversion, Contabo, POST, DELETE, or WebSocket attempt was observed. The Jotform event endpoint remains blocked; no decision has been made to permit it.

The 2026-10-26 recalibration captured another 24 full-page screenshots in:

/tmp/aia-form-a-real-iframe-sizing-8RAs2f

It observed 432 permitted Jotform GET/HEAD requests and blocked 40 requests to https://unpkg.com and https://events.jotform.com; it recorded no AIA production API, analytics, advertising, WebSocket, POST, or DELETE attempt.

After the Early Intervention route addition, a further 2026-10-26 read-only run captured 28 full-page screenshots (seven routes at four widths) in:

/tmp/aia-form-a-real-iframe-sizing-oCqA5n

It observed 504 permitted Jotform GET/HEAD requests and blocked 44 unapproved external GETs. It recorded zero forbidden production API, analytics, advertising, WebSocket, POST, or DELETE attempt. This retained the same read-only guard and did not fill, focus, click, inspect, or submit an iframe control.

At 768px and 1440px, the current English and Spanish contact screenshots visibly contain the full field sequence, message area or prompt, sensitive-information text, and native Submit control. The fixed frame ends after a modest visual margin below Submit, rather than the large blank region produced by the original 1200px allowance. The assessment uses screenshots only: no cross-origin iframe DOM, field measurement, or Jotform submission was accessed. The later landing validation-error scrollbar was reported from a real desktop browser; the bounded final increase above addresses that observed error expansion without a dynamic resize channel.

Under the strict guard, the mobile and landing iframe content did not render in the captured pages even after Jotform asset loading was allowed. The blocked events.jotform.com request is an unresolved Jotform-runtime dependency, not evidence that the endpoint is required. No privacy boundary was weakened to make those screenshots render. The seven parent-side frames still passed their fixed-height, no-overflow, fallback, URL, sandbox, and no-JavaScript assertions at 320px, 390px, 768px, and 1440px.

The initial 2026-10-25 desktop capture showed Builder-only fields intended to be nonvisitor-facing, including formContext, websiteCheck, and notificationReplyTo. Those labels were not visible in the latest desktop screenshots. This is visual evidence only, not a Jotform Builder configuration audit; the account owner must still verify the fields and their conditional visibility.

Remaining acceptance

1. Confirm whether the blocked Jotform event endpoint is necessary and whether its data flow is acceptable. Do not allow it by default.
2. Perform a manual Firefox review of all seven routes at 320px, 390px, 768px, and 1440px against the current Builder CSS. Verify the compact landing form, the Early Intervention card, both mobile contact forms, Spanish wrapping, validation-error expansion, focus rings, and all Submit controls.
3. Test conditional email validation, native Submit behavior, confirmation, and failure states using separately authorized synthetic data only.
4. Reconsider a reviewed cross-origin resize contract only if the manual review identifies a real clip or an unacceptable fixed-height gap. It is not warranted by the guarded evidence alone.
5. Obtain privacy/security, operations, fluent-language, accessibility, and release approval before any live activation.

No production integration, Jotform account mutation, form submission, analytics, deployment, staging, commit, or push occurred.