@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.


On Monday, March 16, 2026 at 6:14:56 PM UTC+5:30 Mike Taylor wrote:

>
> 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/2ce566ab-c9a5-43c8-9842-458909fdca61n%40chromium.org.

Reply via email to