On 3/14/26 3:03 a.m., Chromestatus wrote:
*Contact emails*
[email protected]
*Specification*
https://html.spec.whatwg.org/multipage/interaction.html#autocorrection
*Summary*
The HTML autocorrect attribute allows web authors to control whether
autocorrection should be applied to user input in editable elements
including <input>, <textarea>, and contenteditable hosts. On Windows,
the touch keyboard ignores this attribute and always autocorrects
words. For example, typing "truf" followed by space in an element with
autocorrect="off" yields "true " instead of preserving "truf ". This
feature makes Chrome's TSF integration detect and revert touch
keyboard autocorrections when the focused editable element has
autocorrect="off" set.
*Blink component*
Blink>Editing>IME
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EEditing%3EIME%22>
*Web Feature ID*
autocorrect <https://webstatus.dev/features/autocorrect>
*Motivation*
The autocorrect attribute is defined in the HTML Living Standard and
applies to both form controls (<input>, <textarea>) and editing hosts
(elements with contenteditable). On Android, Chrome correctly
communicates this preference to the soft keyboard via
EditorInfo.inputType flags. On Windows, however, TSF's InputScope
interface has no autocorrect field, so the touch keyboard is unaware
of the page's preference and always autocorrects. This creates a
broken experience for web apps that explicitly disable autocorrection
such as code editors, username/email fields, medical or legal forms,
and any scenario where precise user input must be preserved. This
feature fixes the gap by having Chrome detect and revert touch
keyboard autocorrections at the TSF layer when autocorrect="off" is
set on the focused editable element. Moreover, Autocorrect is
performed only by the touch keyboard's prediction engine. Physical
keyboards and traditional IMEs go through composition ranges and are
unaffected. Firefox also does not honor autocorrect="off" on the
Windows touch keyboard, verified that it autocorrects every time. For
non-touch (physical keyboard), neither browser has autocorrected
behavior.
*Initial public proposal*
/No information provided/
*TAG review*
Not Applicable
*TAG review status*
Not applicable
*Goals for experimentation*
None
*Risks*
*Interoperability and Compatibility*
/No information provided/
/Gecko/: No
signal (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/autocorrect)
/WebKit/: No signal (https://bugs.webkit.org/show_bug.cgi?id=289197)
Is it more correct to interpret "no signal" as "shipped/shipping" for
both Gecko and WebKit? That's my read on comment #2 in the WebKit bug
anyways.
/Web developers/: No signals
/Other signals/:
*WebView application risks*
Does this intent deprecate or change behavior of existing APIs, such
that it has potentially high risk for Android WebView-based applications?
No. This change is Windows-only. It has no impact on Android, Android
WebView, or any non-Windows platform. A kill switch
(kTSFHonorAutocorrectOff) is in place regardless.
*Debuggability*
No DevTools changes needed. This feature operates entirely at the OS
input layer (TSF) and does not introduce new web-facing APIs, events,
or state.
*Will this feature be supported on all six Blink platforms (Windows,
Mac, Linux, ChromeOS, Android, and Android WebView)?*
No
Already supported on Android. This change specifically adds support
for windows TKB.
*Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
Yes
Adding WPT not feasible for this change. Unit tests have been added
for automated testing for the feature. A manual WPT has been created
for the change. Link -
https://wpt.live/html/editing/editing-0/autocorrection/autocorrect-off-touch-keyboard-manual.html
*Flag name on about://flags*
Not Applicable
*Finch feature name*
kTSFHonorAutocorrectOff
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
False
*Tracking bug*
https://issues.chromium.org/issues/487613498
*Estimated milestones*
Shipping on desktop 148
*Anticipated spec changes*
Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github
issues in the project for the feature specification) whose resolution
may introduce web compat/interop risk (e.g., changing to naming or
structure of the API in a non-backward-compatible way).
No
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5196629995028480?gate=6520647549321216
This intent message was generated by Chrome Platform Status
<https://chromestatus.com>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69b50845.050a0220.87ff1.0cb0.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69b50845.050a0220.87ff1.0cb0.GAE%40google.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7f7f80eb-ece8-4559-b5be-06efcf26eb93%40chromium.org.
