Repository navigation
Document -webkit-text-security #240
Description
The non-standard -webkit-text-security property exists in both webkit and blink, but does not seem to be mentioned in the compatibility standard.
We've seen real-world webcompat issues because this property is not implemented in Firefox; see https://bugzilla.mozilla.org/show_bug.cgi?id=1826629 and webcompat/web-bugs#114591.
(There's some information about -webkit-text-security on MDN, but note that it is not entirely complete or accurate at present.)
Note also that -webkit-text-security is entirely distinct from the (questionable) CSS-UI-4 input-security property.
Activity
miketaylr commentedon Apr 14, 2023
Ah, interesting. If Mozilla is willing to land this, we should totally spec it here. Thanks for the report @jfkthame.
jfkthame commentedon Apr 14, 2023
I don't think Mozilla is exactly "keen" on this -- but we felt it unlikely that webkit and blink would be prepared to drop it, given existing usage. If you think that's a possibility, though, that'd be great.
miketaylr commentedon Apr 14, 2023
Yeah, sadly usage is much higher than the typical threshold for a deprecation: https://chromestatus.com/metrics/css/timeline/popularity/322
jfkthame commentedon Apr 14, 2023
Do you know whether that reflects only "direct" usage by authors, or does it also include the use of
<input type=password>, which at least in blink appears to set-webkit-text-securityvia the UA stylesheet?If the latter gets counted as "use of this feature", that could substantially change the picture.
miketaylr commentedon Apr 14, 2023
I suspect the former, given that
<input type=password>usage is much higher (4.5%) https://chromestatus.com/metrics/feature/timeline/popularity/192karlcow commentedon Apr 16, 2023
Let's see online: Github Search for
-webkit-text-securityit seems also used for fingerprinting, I wonder how it might break firefox in another way, by selecting codepath which was not meant to be seen, but most of the time it seems to be used by itself.
There are some interesting usage patterns in terms of UI on why people are using it or more exactly why in some circumstances people do not want to use
type="password"Some hacks people rely on to try to get what they want, aka revealing/hiding the input.
Also the intent to ship from Mozilla for [css-ui-4] Implement "input-security" CSS property
BUT
CSS-UI-4 seems to want to remove the feature.
karlcow commentedon Apr 24, 2023
Mozilla just resolved it as fixed.
https://bugzilla.mozilla.org/show_bug.cgi?id=1826629
miketaylr commentedon Apr 24, 2023
Cool, we should document it then. Patches welcome, etc.:)
miketaylr commentedon Oct 25, 2025
A few references / notes:
https://searchfox.org/firefox-main/source/layout/style/test/property_database.js#11450-11460
https://source.chromium.org/search?q=webkit-text-security
https://github.com/search?q=repo%3AWebKit%2FWebKit+webkit-text-security&type=code&p=1
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-text-security
We can define the values to their corresponding char codes, i.e. 0x25A0, 0x2022, 0x25E6:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/layout_text.cc;l=919-929
https://searchfox.org/firefox-main/source/layout/style/nsStyleStruct.h#1227-1241
https://github.com/WebKit/WebKit/blob/e7856fb3079a6882ac86d485a8763f86d7cf4b63/LayoutTests/editing/input/resources/password-echo.js#L8-L14