Firefox is the only widely used engine not supporting -webkit-text-security, and it seems to be in use in the wild to conceal password fields, as per this webcompat.com report. Chrome Platform Status implies that its usage is low (~0.3%), but slowly growing.

Here's a testcase to exercise this property in a variety of situations.

There's an MDN page at https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-text-security with a bit of information, too.

(updated the testcase to exercise some more cases)

This property:

• accepts values: none, circle, disc, square.
• inherits by default (and can be set on descendants to make them render differently from their ancestor's style, as in e.g. the "reset on child div" line in the testcase)
• does not affect input type="password" (i.e. you can't change or remove the disc password-character-replacement glyphs there using this property)
• seems to affect essentially-all-other[1] text, causing its rendered portions (including preserved whitespace) to literally render (and be copypastable) as:
  Unicode Character “◦” (U+25E6)
  Unicode Character “•” (U+2022)
  Unicode Character “■” (U+25A0)

I haven't tested this with a screen reader; I'm curious if the text reads properly or reads as the replacement-glyphs.

[1] There are a few exceptions which seem to be bugs/quirks, probably not interesting other than as an oddity. Chrome seems to apply it in more places than Safari does, generally. Safari doesn't replace text in the filename portion of input type="file", nor the word "submit" on the input type="image" button, nor the numerals in an ordered list. Chrome replaces all of these, including apparently some bonus space characters in ordered lists. (e.g. they render 3 squares for the 1. list item with zero text at the start of an ordered list.) Neither Safari nor Chrome replace disc marker for unordered lists. Also, for completeness: neither Safari nor Chrome replace the text in popup UI, e.g. the select dropdown, the date-picker UI, and title tooltip hover-text.

(In reply to Daniel Holbert [:dholbert] from comment #1)

There's an MDN page at https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-text-security with a bit of information, too.

FWIW, I notice that the MDN page specifically refers to "characters in a <form> field", but both Safari and Chrome seem to apply it everywhere.

(In reply to Daniel Holbert [:dholbert] from comment #3)

• seems to affect essentially-all-other[1] text, causing its rendered portions (including preserved whitespace) to literally render (and be copypastable) as:
  Unicode Character “◦” (U+25E6)
  Unicode Character “•” (U+2022)
  Unicode Character “■” (U+25A0)

I suspect we could implement the rendering side of this fairly easily, e.g. by piggy-backing off the text-transform mechanism to replace the characters for rendering.

I'm less sure what to do about copy/paste. As I understand it, our copy/paste implementation works off the content in the DOM, and wouldn't easily have knowledge of the applied CSS properties.

In any case, I'm not convinced there's much value in "masking" the characters for copy/paste purposes. If someone has access to the system such that they can copy/paste the "hidden" text into some other context in order to reveal it, they can equally well use View Source or the DevTools Inspector or whatever to just examine the content directly. ISTM the use case here is to reduce the risk of casual "shoulder-surfing", not any sort of real "security" that would block a user who deliberately wants to view the content.

I suspect the webkit/blink behavior of copy/paste arises "accidentally" rather than as a conscious design choice, simply because they copy the "rendered text" rather than the underlying content. This can be seen with things like text-transform: uppercase, which in webkit-family browsers results in the content being copy/pasted as ALL CAPS, whereas in gecko browsers it's copy/pasted in its underlying form.

Once you look beyond simple rendering, the question of which APIs do/don't "mask" the text in webkit-family browsers seems quite arbitrary. I think we should not be drawn in to trying to match their behavior as it stands, as there's no useful logic to it AFAICS.

Example: in Safari or Chrome, load your testcase and drag-select some of the content (e.g. from the beginning to the fieldset). Now open the devtools console, and try examining the selection:

> window.getSelection().toString()
< 'div:\n■■■■■\nimplicitly inheriting into div:\n■■■■■■■■■■■\nreset on child div:\ndiv reset\nspan: ■■■■■\nimg with alt text: \nFieldset:■■■■■■\n■■■■■■■■\n'

They're masking the "secure" text in the result of Selection.toString(). (I'm not sure why, given we could see the text in the source view, or by looking at document.body.textContent, but whatever...)

But wait:

> window.getSelection().getRangeAt(0).toString()
< 'div: Hello\nimplicitly inheriting into div: div inherit\nreset on child div: div reset\nspan: Hello\nimg with alt text: \nFieldset:\nLegendFieldset\n'

So much for "text security".

(In reply to Daniel Holbert [:dholbert] from comment #3)

I haven't tested this with a screen reader; I'm curious if the text reads properly or reads as the replacement-glyphs.

At least with VoiceOver on macOS, it reads as "black square, black square, black square" or similar (in both Safari and Chrome).

Here's a possible patch that seems to work OK in my simple testing so far. WDYT, Daniel -- is this something we should do, despite the lack of an actual standard? (I'm leaning towards it, given that I doubt the other browsers would consider unshipping it, and users will just see it as a Firefox bug; they won't think "oh, this site isn't using the best standards-compliant code"...)

If we do want to go ahead with this, we should add a few tests somewhere.

From a webcompat perspective, I would feel it's better to just ship it and fix bugs as we go along, as it doesn't seem like something that would be more broken by us supporting it with some missing corner cases than just not supporting it at all. We can always move to add it to the Compatibility Standard.

Should we instead do bug 1735384? It has an r+'d patch that I could rebase, and includes the copy-paste support, and would interact well with the context menu support etc.

We could then alias -webkit-text-security: none to that if wanted. I doubt there's a very compelling use case for the other values.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #13)

We could then alias -webkit-text-security: none to that if wanted. I doubt there's a very compelling use case for the other values.

That wouldn't address the original webcompat example here, AIUI, because the site is using a non-password field and applying -webkit-text-security: disc to conceal the text.

Ugh, sorry for missing that... I don't think we should support obscuring random text inputs IMO, that looks like a mis-feature :/

Yeah, it's questionable, but OTOH the other browsers do it and apparently it's actually used, so it becomes a webcompat pain point.... (sigh)

(FWIW, it's not even limited to input elements; it can be applied to pretty much any text.)

Yeah, I'd be OK with shipping a "good enough" implementation here, as a sort of intervention. 0.3% usage is low, but probably above the threshold where other browsers would take action to remove this, I think.

Also, I think this is orthogonal to bug 1735384 (input-security) since the properties apply to distinct sets of elements: input-security only applies to input type='password', whereas -webkit-text-security has no effect[1] on those elements.

[1] (Blink happens to implement this -webkit-text-security restriction (and the disc rendering itself) via an !important rule on password inputs, but that's sort of an implementation detail.)

IMO it's not an implementation detail because it's exposed in the computed style.

(Based on manual testing, it looks like this property is exposed with a non-author-overridable disc value in the computed style for password fields on WebKit as well [in addition to Blink per https://phabricator.services.mozilla.com/D174951#5764386])

I don't see that being a huge issue here; we could add a UA stylesheet rule to expose it in our computed style, too, if we were concerned about that Blink/WebKit computed-style exposure being problematic from an interop perspective. (Even if that happens to not be how we implement the masking under the hood for password fields.)

I've opened https://github.com/whatwg/compat/issues/240 regarding adding this to the compat spec.

Depends on D174951

https://hg.mozilla.org/mozilla-central/rev/c5031904ac17
https://hg.mozilla.org/mozilla-central/rev/0b42da869302