Headed Windows: Google search box focus lands but typed text does not commit or submit

[adybag14-cyber]

Summary

On the Windows headed path, https://www.google.com/ still does not accept end-to-end search input reliably.

Current behavior

• Clicking the Google search box can appear to focus the field.
• The caret state is inconsistent.
• Typed text does not reliably appear in the query box.
• Enter does not reliably produce a search results navigation.

What is already proven working

• The normal Windows headed binary builds and runs.
• Session restore and startup stability fixes are in place.
• Generic focused-input typing works on simpler local headed pages.
• Focus-on-mousedown and the full mouse activation sequence are implemented.
• Legacy named form/control access (document.f, form.q) is implemented.
• Legacy keyboard fields (keyCode, charCode, which) are implemented.
• Parser task deferral after parser-blocking scripts is fixed.

What is not yet working

• Real Google homepage search interaction on the headed Win32 surface.

Current narrowing

This no longer looks like a pure rendering bug.

• The missing blinking caret may be partly visual.
• But the empty query value and lack of submit are real functional failures.
• Simpler local input pages work.
• The remaining failure appears specific to the real Google homepage/runtime path in headed mode.

Repro

zig build -Dtarget=x86_64-windows-msvc --summary all
.\zig-out\bin\lightpanda.exe browse --browser_mode headed https://www.google.com/

Then click the search box and type a query.

Expected

• Visible focus/caret state
• Typed text appears in the query input
• Enter submits to Google search results

Actual

• Focus is inconsistent
• Typed text does not reliably land in the input
• Submit/navigation does not reliably happen

Notes

The completed headed/input/layout groundwork was committed in 76776569 (headed: harden restore input and layout paths)

[adybag14-cyber]

Progress update from the latest headed Windows / Google work:

• Landed and pushed 77a51d1c (Improve headed runtime parity and Google challenge coverage) on fork/headed-mode-foundation.
• Navigator parity was expanded substantially in the live binary. Added/stubbed the Chrome-facing surfaces that were still missing in the headed runtime path, including:
  • geolocation
  • bluetooth
  • hid
  • usb
  • serial
  • locks
  • windowControlsOverlay
  • scheduling
  • managed
  • login
  • ink
  • devicePosture
  • app badge + ad-auction / protected-audience names (setAppBadge, clearAppBadge, runAdAuction, protectedAudience, etc.)
• Re-ran focused Window#navigator coverage after each slice and rebuilt the live binary. /sorry/ capability compare now shows the major navigator own-name gap is effectively closed.

Google-specific progress:

• A direct headed Google search URL now renders successfully in Lightpanda:
  • https://www.google.com/search?q=brass+otter+lantern
  • the headed probe produced a real screenshot (google-search-current.png), so normal Google results rendering is working in the live browser.
• The narrower homepage VK-input probe (google-home-search-vk-probe.ps1) now drives the flow further than before:
  • it produced before.png and after.png
  • stderr shows navigation to a real Google /sorry/ URL for the typed query
  • this is important because it means the browser is no longer just failing locally at focus/caret; under a more user-like path it can now trigger real Google-side challenge flow from the homepage.

What the challenge probes now show:

• google-sorry-dom-dump.ps1 completed and confirmed a real Google challenge path:
  • before state is https://www.google.com/sorry/index?...
  • consent redirect target is https://consent.google.com/ml?...
  • document readyState is complete
• The delayed /sorry/ capture state is even more explicit:
  • href is the real Google /sorry/index?... page
  • iframeCount = 1
  • body text contains the expected “Our systems have detected unusual traffic from your computer network...” text
  • so headed Lightpanda is definitely rendering the actual anti-bot page, not failing earlier in layout/runtime.

Current narrowing after this round:

• This issue is no longer best described as “Google homepage typing never goes anywhere.”
• We now have evidence for three separate states:
  1. direct search URL -> real Google results render in headed mode
  2. homepage VK/input path -> can reach a real /sorry/ challenge
  3. /sorry/ page -> loads fully and exposes the expected challenge shell + iframe in the DOM
• The remaining work is in the interaction layer around the homepage / consent path, not the broad browser runtime:
  • some homepage probes are still brittle because their initial screenshot/readiness gate fails before typing
  • the consent probe currently reports “Accept all button was not visible” on the served consent path
  • one delayed capture script is also flaky on a CDP Page.frameStoppedLoading wait

So this issue has moved forward materially:

• headed runtime / layout / navigator compatibility is much stronger
• direct Google search rendering works
• homepage search can now reach Google’s real challenge flow
• /sorry/ challenge rendering is confirmed end-to-end in the live headed browser

Remaining gap:

• make the homepage search interaction path deterministic enough that typed text + submit consistently land in either normal results or the challenge/consent path without probe-specific timing fragility.