The proposed solution was to use authmanagerinfo to fetch info about the fields to be presented ( as outlined in action=clientlogin docs ) rather than hard-coding them. ( currently we're only using authmanagerinfo to see if captcha is needed ) This would make the interface more responsive to whatever input the auth manager determined was needed.

The issue I'm running into is the authmanagerinfo fields data is incomplete. As I understand it, the point of its fields data is to provide the information needed to present the form. It does so only partially.

For example, with login, the placeholder strings are missing, as is the entire Log in input button* and its string:
( see the orange dots in the screenshots for missing items )

With acct creation, placeholder strings are missing, label strings are outdated ( for example, you can see MW shows Confirm password whereas fields.retype.label says Retype password: ), the Real name field is missing from fields, as is the Create your account input button*:

*Arguably the input buttons are not fields per-se, but when the form is submitted a value can be transmitted associated with the button which was clicked, so they can act as inputs reflecting user choice just as fields like text boxes or checkboxes. Additionally, if other fields need to surround an input button - say above and below - you'd need the input button to be represented in fields to be able to lay out the form with just the fields data.

Arguably, the main take-away is that authmanagerinfo fields is not presently a useful source of truth. Even MW, as seen in the screenshots, has to work around its incomplete/outdated data

Assuming the above is correct ( entirely possible I've missed something 😂 )...

The *best* solution, imo, would be to fix authmanagerinfo fields to deliver updated strings, the missing strings, and the missing form input element data. Then clients could actually use fields to present complete forms, and the source of truth for these forms, so to speak, could live in one place.

Less ideally would be to hack around the incomplete fields data, as it appears MW has.

The problem with the hack around the incomplete fields data approach is I'm not sure we'd end up with anything much more adaptive/flexible than what we have now. i.e. if authmanagerinfo tells us there's this new field to present, but doesn't give us everything we need to present it, then we'd have to add a work-around for that field, cut a new build etc. Basically we'd be left still needing to hard-code some field-specific info - much in the same way we are now.

Side-note: I would be all about taking a hack at fixing authmanagerinfo fields... would be a good learning project!

@Tgr does this make sense?

^ @ItSpiderman and @Osnard re T218211, you might have interest in the comments/have input and the parent task T230043 you might want to subscribe to too

Ping @Anomie too due to questions relating to AuthManager

• Placeholders are not handled by AuthManager, they are an extra flourish added by the web interface (and pretty worthless IMO, since they just repeat the label).
• The login button is indeed not considered a field. (Other buttons might be; e.g. if you use the GoogleLogin extension, there will be a "Login with Google" button. Pressing that does provide extra information on where to go with the process, so that does get considered as a (boolean) field.) It is also specific to the interface - e.g. if you implement the login in the console like mwapi does, you'll just continue the process as soon as the last field was filled out.
• The "Keep me logged in" label is probably customization done by MobileFrontend?
• The different label must also be some kind customization. Probably to have different text for mobile and web, otherwise I can't think of any reason not to change the standard description itself.
• I'm not sure about the lack of the realname field. That seems like a bug.

Bottom line is, the API gives you a functional login form, and clients might want to tweak known fields to make them a nicer experience in their specific context (which the API can't predict). I don't think it's hard to do the tweaks in a way that doesn't reduce the flexibility.