Fix the handling of password fields with the copy and cut actions

[ehsan]

For privacy reasons, UAs typically don't allow the user to cut/copy anything from within the a password field (<input type=password>). The current spec ignores this case in the cut and copy action, and at least in Gecko we're probably not going to implement that. Here is my proposal for how the spec should be changed to deal with this:

I propose the step 3 of the spec should be changed as below:

If the event was not cancelled
    If the currently focused element of the Document is a input element with type=password, return false and abort these steps.
    Copy the selected contents, if any, to the clipboard. Implementations should create alternate text/html and text/plain clipboard formats when content in a web page is selected.
else, if the event was cancelled
    Call the writing contents to the clipboard algorithm, passing on the DataTransferItemList list items, a clear-was-called flag and a types-to-clear list.

And similarly for cut, I propose to change step 3 to:

If the event was not cancelled
    If the currently focused element of the Document is a input element with type=password, return false and abort these steps.
    If there is a selection in an editable context
            Copy the selected contents, if any, to the clipboard. Implementations should create alternate text/html and text/plain clipboard formats when content in a web page is selected.
            Remove the contents of the selection from the document and collapse the selection.
            Queue tasks to fire any events that should fire due to the modification, see interaction with other events for details.
    Else, if there is no selection or the context is not editable
        Do nothing
Else, if the event was cancelled
    Call the writing contents to the clipboard algorithm, passing on the DataTransferItemList list items, a clear-was-called flag and a types-to-clear list.

[annevk]

Not being able to copy passwords you can easily get to through script is actually somewhat annoying. Are we really sure we're helping users here?

[ehsan]

I think a good UX for a password field would be one where the user could click on a button and reveal the contents of the password box. If a UA implements that, they should probably support copying that content as well. But with the traditional password box implementation, I think copying makes no sense. For example, if I have |*********| in my password field, and select the first three stars and copy them, what am I exactly copying to the clipboard? :-)

[garykac]

We (@gked and I) just checked and the only UA that allows the user to show the password is Edge. The other browsers we tested (Chrome Mac, FF Mac/Win, Safari) do not have native support for showing the actual password.

@ehsan 's proposal sounds reasonable. Allow copying only if the password is currently being shown (if the UA supports that). If the password field is displaying '****', then nothing is copied or cut. Paste will always work in password fields.