[<login>] Extend the LocalFrame to query <login>s elements [chromium/src : main]

0 views

Skip to first unread message

Sam Goto (Gerrit)

unread,

Feb 10, 2026, 8:19:41 PM (14 hours ago) Feb 10

to Dominic Farolino, Chromium IPC Reviews, Christian Biesinger, Chromium LUCI CQ, AyeAye, chromium...@chromium.org, Kentaro Hara, Raphael Kubo da Costa, blink-re...@chromium.org, blink-revie...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, npm+...@chromium.org, yigu+...@chromium.org

Attention needed from Christian Biesinger, Dominic Farolino and Nasko Oskov

Sam Goto added 3 comments

File third_party/blink/public/mojom/frame/frame.mojom

Line 1290, Patchset 19: GetFederations() => (array<Federation> federations);

Dominic Farolino . unresolved

Technically per https://docs.google.com/document/d/1Kw4aTuISF7csHnjOpDJGc7JYIjlvOAKRprCTBVWw_E4/edit?tab=t.0#heading=h.jv90dicow9kc, these new methods need to have at least one non-test usage, but they're only really exercised in browser tests and no production path.
https://chromium-review.googlesource.com/c/chromium/src/+/7539587 probably has some "production"-paths. Would it be possible to chain the next CL on top of this one that shows how these are really going to be used? (or point out which parts of that aforementioned CL I should look at to get a feel for how these mojo methods would be used outside of tests)?

Sam Goto

I'm working on a CL that branches of this one that can give a concrete sense of how this CL is intended to be used.
I'll report back momentarily when I set that up.

Sam Goto

Done.

I rebased this and also kicked off two CLs that branches from this one here to give you a concrete sense of how I'm planning to use this.

Something I've been wondering is if LocalFrame is in fact the right architectural choice, rather than this option I described here:

https://chromium-review.googlesource.com/c/chromium/src/+/7543033/comment/c06762eb_895b0ea9/

WDYT?

Line 1293, Patchset 19: DispatchFederationEvent(mojo_base.mojom.UnguessableToken element_id, string token);

Nasko Oskov . unresolved

I find it strange to add mojo IPC methods without actual usage. +1 on dom@'s comment that we should see a bit more of the picture and linking to the future CLs in this one is needed.

Sam Goto

SGTM
Let me rebase some of these changes so that it gets easier to see how this (specifically, the Mojom browser/renderer API changes) is intended to be used.

Sam Goto

I rebased this CL onto another one to decrease its scope to only contain the LocalFrame IPC change.

As requested, the way we are planning to use this is here:

https://chromium-review.googlesource.com/c/chromium/src/+/7563244

And as a consequence here too:

https://chromium-review.googlesource.com/c/chromium/src/+/7563245

Does that help give you a sense of how we are planning to use this?

On a related note, another architectural option that I was considering was to expose the <login> elements via the GetAIPageContent method (rather than the LocalFrame mojom) which is implemented by the AIPageContentAgent via the ai_page_content.mojom.

Because we are only planning to use this for agentic browsing, I think it probably fits there better, than the more broadly available LocalFrame.

Thoughts?

Line 1293, Patchset 19: DispatchFederationEvent(mojo_base.mojom.UnguessableToken element_id, string token);

Dominic Farolino . resolved

What is this supposed to do besides just dispatching a DOM event? What Blink actions are supposed to happen, or what does this indicate?

Christian Biesinger

That's it -- the website is supposed to listen to the event to receive the token that the IDP sent to the browser.
In a regular FedCM call, there's a promise returned from navigator.credentials.get. But in this case, because it's declarative, we instead deliver the token through this event. (Per https://www.w3.org/TR/design-principles/#state-and-subclassing, the token is stored on the federation element, not on the event object)

Dominic Farolino

Ah so Blink literally isn't supposed to take any action besides storing the state, and telling the developer about it here so they can grab it off of the element?

Christian Biesinger

Yes that's correct

Dominic Farolino

What "type" should `token` be? It's a string, but can it be described by any more specific type?

Sam Goto

I have moved this change to this other CL:

https://chromium-review.googlesource.com/c/chromium/src/+/7552493

And replaced `token` for `credential` (and made it currently a `DOMString` -- I'll later want to make it a `Credential` but that requires me to make /core depend on /modules, so I'll do separately).

I'm going to resolve this here and take this discussion to this CL: https://chromium-review.googlesource.com/c/chromium/src/+/7552493

Open in Gerrit

Related details

Attention is currently required from:

Christian Biesinger
Dominic Farolino
Nasko Oskov

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Reply all

Reply to author

Forward

0 new messages