When the login form is nested, how autofill stays usable and safe
Login forms often sit inside iframes on SSO, payment, and portal pages. This article explains how Wowkey shows suggestions on the top page and writes credentials back to the correct nested form.
On many sites, the login form is not on the outer page you opened. It lives in a nested page—technically an iframe. This is common for single sign-on, payment flows, and enterprise portals.
To the user it still looks like one login screen. To a browser extension it is a page inside a page. When that boundary is mishandled, typical failures include:
- no credential suggestions, or a menu in the wrong place;
- passwords written into the wrong page;
- plaintext secrets exposed too early.
Wowkey’s browser extension handles this by discovering and filling inside the nested page, presenting suggestions on the top page, and letting the background match credentials, re-check safety, and dispatch the fill to the right place.
User flow
| Step | What happens |
|---|---|
| 1 | Focus an account or password field in the nested page |
| 2 | Candidate accounts or the extension entry appear |
| 3 | Select an account |
| 4 | Username and password are written back into that form |
The key difference from a normal page:
Suggestion menus are drawn on the outermost page so they stay clickable; the password is written into the nested field so the fill is correct.
In short: UI on top, fill on the nested page.
Why scanning only the top page fails
Nested pages often come from another origin. Outer-page scripts cannot read their DOM. If an extension only scans the top document, the real login form is invisible.
Wowkey therefore recognizes username and password fields in every relevant document, including nested pages.
Roles
| Role | Where | Responsibility |
|---|---|---|
| Discovery and fill | Each page / nested page | Find fields, compute menu position, write values |
| UI | Outermost page | Show candidate lists, icons, and prompts |
| Coordination | Extension background | Track which tab and nested page owns the form; match vault items; re-check; dispatch fill |
Goals:
- Discoverable — nested login forms can still be found;
- Clickable — menus are less likely to be clipped or covered;
- Correct — values are written in the original nested page, not an outer field.
Design
1. Browser-authoritative page identity
A host page may contain several nested regions. Wowkey uses browser-authoritative information to identify:
- the current browser tab;
- the nested page that owns the login fields.
Fill tasks are sent only to that target page, not to a sibling region or the outer page.
2. Layer-by-layer menu positioning
Field geometry is measured inside the nested page; the menu is drawn on the top page. Wowkey converts coordinates upward layer by layer so the menu can sit near the focused field.
Coordinate conversion only affects menu placement. It does not decide which nested page receives the password—routing does.
3. Match credentials to the nested page URL
On SSO and payment pages, the nested page URL often differs from the host page. When matching vault items, Wowkey uses the URL of the page that hosts the login fields, not only the outermost site.
4. Release secrets only after selection
While suggestions are shown, users see available accounts—not plaintext passwords on the page. After selection, the extension:
- confirms the target field still exists and the page has not navigated away;
- confirms the credential still matches the current login URL;
- applies extra checks for weaker connections and cross-site nested pages;
- releases the secret and builds a short-lived fill task;
- sends that task only to the original nested page.
5. Final checks before writing
When the nested page receives the task, it also checks:
- whether it is still the target document;
- whether the task is still valid;
- whether the environment allows automatic writing.
Only then does it write values and fire input events so the site can continue its login flow.
Design goals
| Goal | Approach |
|---|---|
| Find nested login forms | Each nested page discovers its own fields |
| Avoid filling the wrong page | Browser-authoritative page identity; precise task routing |
| Keep menus usable | Render on the top page; align with full-page coordinates |
| Avoid early secret exposure | Release plaintext only after selection and checks |
| Do not force-fill after page changes | Re-check after selection; time-bound tasks; final checks before write |
| Extra caution in sensitive cases | Weaker connections and cross-site nested pages follow security and privacy settings |
Limits
| Situation | Notes |
|---|---|
| Login form inside a nested page | Supported: discover, show suggestions, fill back |
| Deep nesting | Layer-by-layer positioning is supported; menus may shift slightly in extreme depth, but the wrong page should not be filled |
| Username on the outer page, password inside a nested page | Usually cannot complete both in one fill |
| Accounts that require extra verification | Automatic fill may be refused |
| Strictly restricted nested environments | Automatic writing may be unavailable |
Summary
When the login form is nested, Wowkey’s path is:
Discover and fill inside the nested page; present choices on the top page; match credentials, re-check safety, and dispatch the fill precisely in the background.