Web: `TextField.focus()` after `on_submit` discards keys typed while the focus request is in flight

オープン
  • 何か問題がありますか？
#7,059 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
flutter, python, web-dev
領域
frontend, mobile-dev

調査の方向性

Start by tracing how Enter affects TextField focus in the web client, then follow the client handling of the focus() method invoked from Python. The issue provides a minimal app and reproducible Playwright steps; use those to compare input value and active element around the focus request. Done means the retyped characters are preserved or Enter can keep focus, with the behavior verified against the reported cases.

索引モデルが issue の本文から書いたものです。

説明

Flet: 1.0.3 (stock, no other code). Browser: Chromium headless shell (Playwright), mobile emulation 390x844
with touch; macOS host. Mode: web (ft.run(main, view=None, port=8772)).

What happens

On web, pressing Enter in a TextField takes focus away from it: the field's <input> is removed and focus moves to
flutter-view. This happens with or without an on_submit handler. To let the user retype without tapping the field
again, the handler calls await field.focus(). Keys the user types after the Enter and before that focus request
lands in the client are lost. Once focus is back, the field holds only the keys typed after it arrived.

Minimal app

import flet as ft

def main(page: ft.Page):
    password = ft.TextField(label="Password", password=True)

    async def on_submit(e):
        print("submit", "empty" if not e.data else "nonempty")
        if not e.data:
            await password.focus()   # let the user retype without tapping the field

    password.on_submit = on_submit
    page.add(password)

ft.run(main, view=None, port=8772)

Steps

Each run uses a fresh browser context.

  1. Click the field.
  2. Press Enter with the field empty.
  3. Type a 14-character value with no click.
  4. Press Enter.

Each run records the DOM value and document.activeElement after every key, and compares the second on_submit
value with the typed text: exact, prefix lost, or empty.

Results (n=20 per arm)

arm timing second submit
focus() in the handler typing starts at once after the Enter 0/20 exact, 20/20 prefix lost
focus() in the handler typing starts 250 ms after the handler ran, then 120 ms per key 19/20 exact, 1/20 prefix lost
focus() only, no other update in the handler at once 0/20 exact, 20/20 prefix lost
no focus(), the test clicks the field again right after the Enter at once 20/20 exact
no focus(), no click 0.3 s after the handler ran the keys go nowhere: no second submit in 20/20
no on_submit at all; Enter caught by page.on_keyboard_event at once the field loses focus within a few keys of the Enter in 20/20; the retype never reaches it (second submit empty in 20/20)
no on_submit, no keyboard handler at once the same: the field loses focus after the Enter in 20/20 and keeps none of the retype

TextField.focus() is only _invoke_method("focus") on the Python side, so the reset happens in the web client when
the focus request is handled. In 2 runs the DOM <input> was briefly absent as the focus landed: the editing element
appears to be recreated.

Expected

Either:

  • Enter on a TextField can keep its focus (an option, or no blur when on_submit does not ask for it); or
  • focus() on a field that the user is already typing into keeps the characters typed so far.

Caveat

Playwright key events are not a phone's soft keyboard. We have not measured a real device's Go key.

主要言語
Python
スター
17.5k
フォーク
740
平均マージ
1日 8時間
マージ済み PR（30日）
74

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

flet-dev/flet のほかの issue

flet-dev/flet の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。