Intent to Ship: Respect autocorrect="off" for Windows touch keyboard in TSF

[Chromestatus]

Contact emails

prana...@microsoft.com

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

Web Feature ID

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)

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?

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.

[Mike Taylor]

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.

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69b50845.050a0220.87ff1.0cb0.GAE%40google.com.

[Christian Biesinger]

On Sat, Mar 14, 2026 at 3:03 AM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

prana...@microsoft.com

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.

Just curious -- TSF here means text services framework? It's basically an IME framework?

Christian

 

--

[Pranav Modi]

@Mike,

Our I2S is specifically about the behavior of suppressing Windows touch keyboard autocorrection when autocorrect="off" is set, not about shipping the autocorrect attribute itself.

Gecko: Firefox shipped the autocorrect attribute in v136, but does not suppress Windows touch keyboard autocorrection — we verified that Firefox still autocorrects with autocorrect="off" on the Windows touch keyboard. So "no signal" is accurate for this specific behavior.
WebKit: Safari supports the autocorrect attribute (originated on iOS, where it controls the iOS keyboard). Safari doesn't run on Windows, so this Windows-specific behavior is N/A.

The attribute support and the platform-level enforcement are separate concerns. We're shipping the latter for Windows.

[Pranav Modi]

@Christian,

Yes, TSF (Text Services Framework) is Microsoft's COM-based API for text input on Windows. It serves as the interface between applications and input processors, including IMEs (for CJK languages etc.) and the Windows touch keyboard.

[Dan Clark]

> Gecko: Firefox shipped the autocorrect attribute in v136, but does not suppress Windows touch keyboard autocorrection — we verified that Firefox still autocorrects with autocorrect="off" on the Windows touch keyboard. So "no signal" is accurate for this specific behavior.

In this case I think it makes sense to file a Firefox bug so they could also make this fix.

-- Dan

[Daniel Bratell]

LGTM1

/Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a0515f17-93dd-4f90-b468-20159852aa5fn%40chromium.org.

[Dan Clark]

LGTM2 but please do file the Firefox bug.

[Chris Harrelson]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ac2d4623-f2da-49cd-8fb9-412d94f18889n%40chromium.org.

[Pranav Modi]

A bug has been raised on Firefox for the issue. Track: 2024908 - Windows touch keyboard ignores autocorrect="off" on input/textarea and content-editable elements