The dialog version of the TOTP page does autofocus for me in Safari and Chrome, at least (Workflow.js near line 338 focuses the most-upper input, text area, or button after showing a dialog).

We don't currently ever focus inputs on standalone pages on load. We could, but it's possible this would do some weird stuff, so I'd be slightly hesitant to just start doing it without some testing/consideration. Offhand, maybe there'd be a weird jumpy behavior on pages like Conduit API pages, where the first input that gets focused is way way down the page? For those pages, at least, it seems preferable not to focus anything by default.

A safe change might to be to run the same focus code when dialogs render as standalone pages (that is, only on the "render dialog as standalone" pathway, not the "render any standalone page" pathway). Since we know these pages also render as dialogs sometimes and thus get the focus code run on them, this should always be safe, although the code will need to be careful to focus only inputs in the dialog itself, not inputs on the whole page (otherwise, it will always just focus the global menu bar search field, I think). We might also need to do a little planning around what happens with the persistent chat thing when other stuff tries to steal focus -- it seems like we currently de-focus it even if you're in the middle of typing something, which seems not-so-great.

Upshot: probably not one line, but maybe a tractable change? Happy to review either the "focus standalone dialog pages" or "focus every page" changes, the latter just might need some babysitting and a mess of a test plan involving Quicksand, persistent chat, etc.