Bug 219020 - navigator.clipboard is not exposed on *.localhost pages
Summary: navigator.clipboard is not exposed on *.localhost pages
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: Safari 14
Hardware: Macintosh macOS 10.14
: P2 Major
Assignee: Chris Dumez
URL: https://w3c.github.io/webappsec-secur...
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-11-16 21:33 PST by Martin Häcker
Modified: 2020-11-18 11:49 PST (History)
12 users (show)

See Also:


Attachments
Patch (4.18 KB, patch)
2020-11-18 07:57 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Häcker 2020-11-16 21:33:01 PST
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?
Comment 1 Martin Häcker 2020-11-16 21:33:16 PST
Might be related to https://bugs.webkit.org/show_bug.cgi?id=206653
Comment 2 Alexey Proskuryakov 2020-11-16 22:24:55 PST
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?
Comment 3 Martin Häcker 2020-11-17 00:05:11 PST
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?
Comment 4 Alexey Proskuryakov 2020-11-17 16:45:43 PST
Probably something about what's considered a secure context. CC'ing some people who would know more about recent changes there.
Comment 5 Chris Dumez 2020-11-17 16:48:15 PST
(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.
Comment 6 Ryosuke Niwa 2020-11-17 16:48:36 PST
Async clipboard API is only available on HTTPS pages.
Comment 7 Chris Dumez 2020-11-17 16:51:29 PST
(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.
Comment 8 Chris Dumez 2020-11-17 17:07:34 PST
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.
Comment 9 Chris Dumez 2020-11-18 07:57:42 PST
Created attachment 414451 [details]
Patch
Comment 10 EWS 2020-11-18 08:39:43 PST
Committed r269960: <https://trac.webkit.org/changeset/269960>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 414451 [details].
Comment 11 Radar WebKit Bug Importer 2020-11-18 08:40:16 PST
<rdar://problem/71540839>
Comment 12 Darin Adler 2020-11-18 11:49:17 PST
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.