Should clipboard actions consider whether selection has focus? about clipboard-apis HOT 6 CLOSED

A focused selection is always visible. In this case we have a visible but unfocused selection.

Users expect effective CTRL+C/V/P anytime a selection is visible? In this case, users can't know if the selection is focused or not. They see a blue selection so they expect interaction with it?

To fulfill that expectation, maybe CTRL+C/V/P should move focus to a visible&&unfocused selection? Hmm, could be complicated; the focus move would need to be done after any ClipboardEvent handler has had a chance to cancel the default operation => ClipboardEvents must target the visible selection.

Either way, I think it is safe to spec:
"Set target to be the element that contains the start of the visible selection in document order, or the body element if there is no visible selection or cursor"

from clipboard-apis.

I'm not sure if users expect effective cut/paste when there is unfocused visible selection. It can be confusing if cut/paste still modifies content of a contenteditable even though the user has explicitly moved the focus away.

And at least for Chrome, focused and unfocused selection have different appearance. In Chrome, a focused element has a light blue border. Hence, the user can tell whether selection is focused by checking if the selection is inside the light blue border or not.

from clipboard-apis.

As @xiaochengh pointed out when selection is greyed out this is the true case of loss of focus. Browser doesn't really takes away the focus when clicking on the checkbox in your example. Being in focus is still a requirement to effectively being able to insert into DOM (by the user, I mean).

Also, I am pretty sure all browsers send visual queues to the user if a selection is not in focus so there is not confusion to the user.

Perhaps, we could add an constrain to the first part of the statement - "...element that is in focus and contains the start of the visible selection in document order"

from clipboard-apis.

Browser doesn't really takes away the focus when clicking on the checkbox in your example.

Focus is moved to the checkbox according to document.activeElement... but the (now unfocused) selection can still be copied with CTRL+C.

And at least for Chrome, focused and unfocused selection have different appearance. In Chrome, a focused element has a light blue border. Hence, the user can tell whether selection is focused by checking if the selection is inside the light blue border or not.

Ah yes! True that. I didn't think about that "focus-box". I just saw the blue selection. The selection is unfocused but can still be copied with CTRL+C so it makes sense that it is blue even tough it is outside of the focus-box. In this case, what should be the copy ClipboardEvent's target? Answer: the selected element (not document.body). All browsers do this already.

If we say,

"...element that is in focus and contains the start of the visible selection in document order"

In the checkbox-case, the selection is not in focus (if you ask document.activeElement) => The copy event would target document.body and not the selected element (wrong). That's why I think it's better if we use the word "visible". The word "focus" can be a little bit ambiguous in this context?

from clipboard-apis.

Note that on macOS & iOS, there is no distinction between selection & focus. Focus always moves to wherever selection is last set by the user.

from clipboard-apis.

Now that the spec update has landed, let's close this?

from clipboard-apis.