fix(forms): Safari focused none of them, and a board could not make a section

Two reports, one sentence between them: "sections have no function, because you
cannot create more than one."

`autofocus` does not work in Safari for anything inserted after the page has
loaded, and every inline form here is inserted after the page has loaded — rename
a project, add a section, name a group. In Safari they all opened with no cursor
in them and what you typed went nowhere. That does not look like a bug. It looks
like the feature does not work. `use:focusOnMount` replaces all seventeen.

And the board had no way to add a section at all. The button lived only in the
list view, which is the one place nobody looks for it: a column on a board *is* a
section, so that is where you go to make one.

Chasing this turned up a third. The task drawer's three fields save on blur, and
closing the drawer *is* a blur — the input is being unmounted and the browser
fires blur on the way out. If the task left the store in the same moment, `task`
was already null and the handler threw `Cannot read properties of null`, stopping
the page. It only became reproducible once focus actually worked.

Fields are 16px on a touch device now, whatever the component asked for. Below
16px, iOS Safari zooms in when a field takes focus and does not zoom back out —
so the whole interface is left too large and has to be pinched back by hand, once
per field. The type scale tops out at 15px, so every input in the app did it.

The sidebar's resize handle sat at `right: -3px`. An absolutely positioned child
counts towards its container's scrollable overflow, and `overflow-y: auto`
resolves the other axis to `auto` too — so those three pixels gave the whole menu
a horizontal scrollbar on every desktop, always. The account name could do it as
well: `overflow: hidden` with no `min-width: 0` cannot shrink, so the row grew
instead of ellipsing.

There is a WebKit pass in the suite now, over one test. The rest stays Chromium
on purpose — a smoke test exists to catch a build that does not work, and three
engines find the same bug three times — but focus is the exception, and it took a
person using the app to find that out.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Kristian Wind
2026-08-18 09:05:02 +02:00
co-authored by Claude Opus 5
parent 1da7ea64bf
commit eaff890860
9 changed files with 575 additions and 18 deletions
+26
View File
@@ -65,6 +65,32 @@ export default defineConfig({
name: 'chromium',
use: { ...devices['Desktop Chrome'], storageState: 'e2e/.auth/user.json' },
dependencies: ['setup']
},
/**
* A short WebKit pass over the forms, and nothing else.
*
* The rest of this suite is Chromium only on purpose: a smoke test exists to
* catch a build that does not work, and running it in three engines finds the
* same bug three times. Focus is the exception, and it cost a real report to
* learn it. Safari ignores the `autofocus` attribute on anything inserted
* after the page has loaded — so every inline form in this app opened with no
* cursor in it, and what you typed went nowhere. It does not look like a bug;
* it looks like the feature does not work. "Sections have no function,
* because you cannot create more than one" was this.
*
* One test, not four. The engines share this server and this database, so a
* second pass over tests that create projects by name collides with what the
* first pass already made — which fails as a name that is suddenly ambiguous
* rather than as anything about WebKit. The sections test is the one that
* earns the second engine, because it is the one the focus bug broke.
*
* WebKit here is the same engine Safari is, which is the whole point.
*/
{
name: 'webkit-forms',
grep: /@forms/,
use: { ...devices['Desktop Safari'], storageState: 'e2e/.auth/user.json' },
dependencies: ['setup']
}
],