Bug 219020 – navigator.clipboard is not exposed on *.localhost pages

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Martin Häcker]

navigator.clipboard and with it navigator.clipboard.writeText is gone from Safari Version 14.0.1 (15610.2.11.51.10, 15610) as well as from Technology Preview Release 115 (Safari 14.1, WebKit 15611.1.3.5). I am pretty sure it was there at least in Safari 13, and also seems to be listed as supported on https://webkit.org/status/#?search=clip as well as on https://caniuse.com/mdn-api_clipboard_writetext (which is why I am using it).

Not sure how this could slip by?

[Martin Häcker]

Might be related to https://bugs.webkit.org/show_bug.cgi?id=206653

[Alexey Proskuryakov]

I'm on exactly the same build right now, and javascript:alert(navigator.clipboard) on this Bugzilla page shows it just fine, and so does Web Inspector console.

Could you please elaborate? A rogue extension perhaps?

[Martin Häcker]

This was tested with all extensions disabled.

I am indeed stumped. The property is available on this bugzilla, but not in the webpage I'm working when I'm serving them on subdomains of localhost, like yeepa.localhost:8080, while it is available again no localhost:8080.

¿¿¿

Is there anything special about subdomains of localhost so this is supposed to happen there?

[Alexey Proskuryakov]

Probably something about what's considered a secure context. CC'ing some people who would know more about recent changes there.

[Chris Dumez]

(In reply to Alexey Proskuryakov from comment #4)
> Probably something about what's considered a secure context. CC'ing some
> people who would know more about recent changes there.

Ever since navigator.clipboard was introduced in r250824, it was only exposed to secure contexts AFAICT.

[Ryosuke Niwa]

Async clipboard API is only available on HTTPS pages.

[Chris Dumez]

(In reply to Ryosuke Niwa from comment #6)
> Async clipboard API is only available on HTTPS pages.

or localhost or 127.0.0.1.

Subdomains of localhost are probably not treated as secure. Looking at our code, the host needs to be exactly "localhost" or "127.0.0.1" to be treated as secure, unless the protocol is HTTPS.

[Chris Dumez]

Spec is here:
https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-origin

It does say that "*.localhost" is secure so we do have a bug indeed. This is not a recent regression AFAIK though.

[Chris Dumez]

Created attachment 414451 [details]
Patch

[EWS]

Committed r269960: <https://trac.webkit.org/changeset/269960>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 414451 [details].

[Radar WebKit Bug Importer]

<rdar://problem/71540839>

[Darin Adler]

Comment on attachment 414451 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=414451&action=review

> Source/WebCore/page/SecurityOrigin.cpp:608
> +    if (equalLettersIgnoringASCIICase(host, "localhost") || host.endsWithIgnoringASCIICase(".localhost"))

Funny and arbitrary that we don’t have endsWithLettersIgnoringASCIICase. It’s just never been added, since we do have startsWithLettersIgnoringASCIICase.