[lippdev]

Stacked on #104 ← #103 ← #101.

Summary

• New tab = ready to type. Navigation.newTab now calls Shell.typeInAddress(), which runs enterChrome() and then opens the keyboard on the address. That covers the + button, Ctrl+T, the menu and --new-tab.

  • Confirming the address sends focus-page, so the page that loads gets the D-pad, as in Edge.
  • A tab view grabs the window's focus about 10 ms after it is attached (traced with focus events). While the keyboard types into the address, the shell takes the focus back on the next tick. It has to wait a tick because the tab is told it gained focus before the shell is told it lost it.

• Address field follows the tab until the user types in it. Before, a field that kept the focus stayed blank while the page loaded.

• Pointer from the reference: a white arrow with a black edge, which turns into a pointing hand over links, buttons, form controls and anything with cursor: pointer. The tip of the arrow and of the finger is the click spot.

• Smooth movement. Measured as distinct positions drawn per second while the stick is held:

  • before: 15/s, with gaps up to 83 ms
  • stick read every poll, scaled by elapsed time: 39/s
  • plus the page gliding to the newest position on requestAnimationFrame: 137/s (on the 144 Hz test monitor)

  The main process also draws only the newest position (no queue). Clicks always use the newest position, never the drawn one.

Test plan

• npm run typecheck
• npm test (118 passed)
• npm run test:e2e (61 passed, 3 skipped), with two new tests:
  • a new tab opens with the keyboard up and the shell holding the focus, and the D-pad types into the address
  • the pointer is an arrow over plain content and a hand over a button
• Screenshots of the arrow and the hand; frame-rate measurement before and after

🤖 Generated with Claude Code