1801880 - Copying password from Password Manager on MacOS does not set the right PasteboardType

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P3)

Description

[Thomas Lima]

Steps to reproduce:

1> Open Firefox on MacOS 13.0.1 (I suspect other versions are similarly impacted)
2> Click options, Passwords
3> Find a previously saved login&password combo.
4> Click the Copy button next to the password

Actual results:

Password successfully copied as plaintext. However, pasteboard type reads public.utf8-plain-text. I use a free application called "Pasteboard Viewer" to verify this.

Expected results:

Pasteboard type should be set to both public-utf8-plain-text and org.nspasteboard.ConcealedType. Google Chrome successfully does this.
My use case is that I use a clipboard manager and would like to ignore copies of passwords and other sensitive data.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Kris Wright :KrisWright]

This bug is reproducible in the current version of Firefox, and the reason is that the calling method never sets the concealed type. Only MacOS should be affected by this issue. I will have a fix up for this soon.

Comment 3

[Thomas Lima]

Thank you!

Comment 4

[Kris Wright :KrisWright]

Attachment: Bug 1801880 - use nsPasteBoard's ConcealedType on password strings.

From my understanding of the issue, we want to preserve the utf8 string type while also adding the org.nspasteboard.ConcealedType as an indicator that a string is private data. I do this by creating a new type to add to the key/value dict we use to set clipboard data. While we handle this on Windows via a flag the windows API provides us, it looks like on MacOS we need to manually specify the data information. I'm unsure if this is quite what the OS intends to see, but with a lack of baseline information from Apple or from testing Safari behaviors, it looks like this might be the right way to go about it.

Comment 5

[Stephen A Pohl [:spohl]]

Kris, in case you weren't aware: you can use an app such as Pasteboard Viewer to see what's placed on the pasteboard. This could help you identify what Safari does in this situation and confirm our behavior against it, before and after your patch.

Comment 6

[Thomas Lima]

The issue is Safari doesn't have a password manager, this is why I looked at what Chrome did. (chrome://password-manager/passwords)

In Chrome, copying a password and inspecting Pasteboard Viewer yielded two key/value pairs. One was "public.utf8-plain-text" with the password string, and another was "org.nspasteboard.ConcealedType" with an empty value.

Interestingly, the Keychain Access app does not set the ConcealedType correctly either.

Comment 7

[Stephen A Pohl [:spohl]]

(In reply to Stephen A Pohl [:spohl] from comment #5)

Kris, in case you weren't aware: you can use an app such as Pasteboard Viewer to see what's placed on the pasteboard. This could help you identify what Safari does in this situation and confirm our behavior against it, before and after your patch.

I see now that comment 0 already mentioned Pasteboard Viewer. Maybe the direct link to the app can be helpful.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ae572fb876bc
use nsPasteBoard's ConcealedType on password strings. r=mac-reviewers,bradwerth

Comment 9

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/ae572fb876bc