Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Link panel stealing focus is way too aggressive when using mouse #4732

Closed
oleq opened this issue Sep 12, 2016 · 3 comments
Closed

Link panel stealing focus is way too aggressive when using mouse #4732

oleq opened this issue Sep 12, 2016 · 3 comments
Assignees
Labels
domain:ui/ux This issue reports a problem related to UI or UX. package:link type:bug This issue reports a buggy (incorrect) behavior.
Milestone

Comments

@oleq
Copy link
Member

oleq commented Sep 12, 2016

A followup of https://github.com/ckeditor/ckeditor5-link/issues/23.

At this moment when clicking a link in the content, the panel is displayed, which steals editable focus and moves it to the URL field inside of the panel. This behavior is, however, very aggressive and may be considered a bug in some cases. For instance, if the user wants to fix a typo in the text of the link (not href) and they use mouse to put the caret at the right position, the link panel will appear and steal the focus. Then the user must use ESC or "Cancel" to go back to editable and do actual editing. Pretty annoying, IMO.

This could be the reason why some editors (Google Docs, Medium) use 2–step editing – the first one appears just to inform the user about the link and editing possibilities (edit, unlink)

image

and the second one, which actually will steal the focus from editable

image

I see 2 possible solutions.

Implement 2–step editing

It makes some sense and solves the focus issue. OTOH it kills the smooth, simple editing experience we expect in CKEditor 5.

Use different approaches when editing with mouse and keyboard.

The current approach (steal the focus) could be preserved for keyboard editing

image

but for mouse editing and navigation, I'd leave up to the user whether to edit in editable or change the href. In such situation, the panel would remain open and follow the selection as the user types.

image

WDYT?

@fredck
Copy link
Contributor

fredck commented Sep 12, 2016

For sure, the fact that the panel appears doesn't mean that it should still the focus. This should happen exclusively when the link command is executed (e.g. CTRL+L or link button). On simply selection change, it is ok to have the panel showing up, but the selection is still in the editor.

This approach MAY cause some confusion as users may think that the panel has focus once it shows up.... or MAY not. One option is moving forward with the current approach (except the wrong focus stealing) and, if people start complaining, we introduce the 2-step process.

@oleq
Copy link
Member Author

oleq commented Sep 13, 2016

I'm for "Use different approaches when editing with mouse and keyboard." because it easiest to implement ATM. It's a low–cost enhancement. It's simply about not selecting the content of the URL input if the panel was opened by clicking an element in editable:

  • Selection in a non–link content -> clicking the link button in the toolbar -> focus stolen by the
    URL field in the panel, which is empty.
  • Clicking a link element in the editable -> panel opens but the focus remains in editable.
  • Selection in a link element -> CTRL+L -> focus stolen by the
    URL field in the panel.

It makes sense to me and enhances the editing experience.

@oskarwrobel oskarwrobel self-assigned this Sep 19, 2016
@Reinmar
Copy link
Member

Reinmar commented Sep 22, 2016

Fixed by ckeditor/ckeditor5-link#34.

@Reinmar Reinmar closed this as completed Sep 22, 2016
@mlewand mlewand transferred this issue from ckeditor/ckeditor5-link Oct 9, 2019
@mlewand mlewand added this to the iteration 3 milestone Oct 9, 2019
@mlewand mlewand added domain:ui/ux This issue reports a problem related to UI or UX. module:ux type:bug This issue reports a buggy (incorrect) behavior. package:link labels Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:ui/ux This issue reports a problem related to UI or UX. package:link type:bug This issue reports a buggy (incorrect) behavior.
Projects
None yet
Development

No branches or pull requests

5 participants