RichText: restore focus after setting selection #17617

ellatrix · 2019-09-26T17:44:46Z

Description

Attempt to NOT return focus to rich text after applying formatting, if focus has been moved elsewhere. This will now be the default for all buttons.

RichText will still allow focus to be set if it is desired, through onChange( value, { focus: true } ). This can be useful if you know that the currently focussed element will be removed from the DOM. This is the case for the link pop up UI.

How has this been tested?

See #17505.

Screenshots

Types of changes

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
My code has proper inline documentation.
I've included developer documentation if appropriate.

This reverts commit 1ab4854.

mcsf · 2019-09-27T08:31:07Z

Whether we return or don't return focus in any given situation, this is generally a difficult problem full of nuance.

For instance, with accessibility in mind, should we make a distinction between clicking on a toolbar control (like Bold) and selecting it with the keyboard? If I select a portion of text and move my mouse to toggle Bold, then I may expect to resume typing, thus focus should be returned to RichText. On the other hand, if I select text, then work my way up to the toolbar controls using Alt+F10 and some tabbing, then perhaps after toggling Bold with Space or Enter I would still like to tab to Italic or Link, especially since the toolbar is still visible. In that case, is my user expectation that I can still tab within the toolbar unreasonable? I have no idea!

ellatrix · 2019-09-27T08:43:54Z

@mcsf I couldn't agree more.

I definitely think that focus should remain in the toolbar if you tabbed all the way there. Perhaps to use other tools, or change your mind.
I also think that it would be good for focus to return to the text if you merely click the button... But this seems a more tricky situation to solve. Sometimes (the colour picker is a good example here) you don't want a mere click to return focus. In case of the link UI, there's also a lot more going on than just a click. Ideally, at the end, on submitting the link, I'd expect focus to go to the toolbar where you can view the link.

On the other hand, it kind of also makes sense that focus stays on the button, even if you merely clicked it. After all, you still clicked it, and therefore moved focus? I'm not sure about this one. Most editors do seem to return focus for a simple button click though.

Considering all this, it does seem best if rich text is not focussed after applying formatting, and to add exceptions from there.

It's also worth noting that selection is NOT focus. While we do not move focus, we still maintain the selection.

ellatrix · 2019-09-27T08:51:08Z

@mcsf We could built that special focus return behaviour into RichTextToolbarButton.

mcsf · 2019-09-27T08:52:51Z

Most editors do seem to return focus for a simple button click though.
[…]
It's also worth noting that selection is NOT focus. While we do not move focus, we still maintain the selection.

Yeah. I wonder if any editors handle this a bit more smartly, perhaps:

Whether with the mouse or keyboard, pressing into the Bold control does move focus to it.
Thus, any additional tabbing will move focus within the toolbar.
However, because selection remains on a portion of text, the editor knows that certain interactions — specifically, moving around with the keyboard arrows — are to be caught so that, then and only then, focus can be returned to the actual rich text.

mcsf · 2019-09-27T08:53:24Z

@mcsf We could built that special focus return behaviour into RichTextToolbarButton.

Yeah, that sounds a bit in line with what I simultaneously commented. :)

ellatrix · 2019-09-27T09:59:59Z

Ok, I've modified RichTextToolbarButton to focus the last active element (rich text) if the button is clicked with the mouse. If the button is pressed otherwise, focus will remain on the button. I think this is good behaviour now.

ellatrix · 2019-09-27T10:01:01Z

packages/e2e-tests/specs/__snapshots__/rich-text.test.js.snap

@@ -76,14 +82,14 @@ exports[`RichText should transform backtick to code 2`] = `
 <!-- /wp:paragraph -->"
 `;

-exports[`RichText should update internal selection after fresh focus 1`] = `
+exports[`RichText should undo backtick transform with backspace 1`] = `


These tests were not in alphabetic order... Jest reordered them.

ellatrix · 2019-09-27T10:37:48Z

This PR is ready for review now.

jorgefilipecosta

Hi @ellatrix, this PR fixed the popover and seems an overall improvement 👍

I tested this PR together with advanced rich text plugin and I noticed the following issue not sure if related to this PR:
If we select some text and then go to the inline color format on the color popup we change the color to red using the input field, the color red is correctly applied, if we go to input field and type green the green is correctly applied, if then I type red again the color is not applied anymore and even if I change the color clicking on the visual color picker the color still does not applies.
Basically the color input works two times but stops working on the third.

Another thing I noticed is that if I click on the bold or italic formats and then I press the arrow keys it moves the cursor on the paragraph but if I use code or subscript format then pressing right-left keys moves the focus on the toolbar buttons. I guess this is expected right given the new way we handle the focus?

ellatrix · 2019-09-27T12:24:24Z

@jorgefilipecosta Thanks for testing! It seems that focussing the input field will also move selection... a document can normally have not more than one selection. I need to think about how we can solve this... :/ Also now I see that for any button in the collapsed menu, focus won't be set back to rich text, but to the toggle button. That's because we look at the last focussed element. The only fix I think it to pass the rich text element to RichTextToolbarButton.

ellatrix · 2019-09-27T12:25:31Z

So, to recap the selection issue: I don't know how we can both allow rich text selection and input field selection. 🤔

jorgefilipecosta · 2019-09-27T12:30:22Z

Testing PR #16014 with this branch produces an even stranger dancing behavior:

It seems like problems only happen when the format contains an input field.

ellatrix · 2019-09-27T12:35:08Z

Ok, found the issue. Working on a fix now.

ellatrix · 2019-09-27T12:41:02Z

@jorgefilipecosta Does the latest commit fix the issue with the colour picker? To me it looks good now.

ellatrix · 2019-09-27T12:44:58Z

I'll now try to fix the clicking for the buttons in the collapsed menu.

jorgefilipecosta · 2019-09-27T13:50:22Z

packages/format-library/src/link/inline.js

 		} else {
-			onChange( applyFormat( value, format ) );
+			onChange( applyFormat( value, format ), { focus: true } );


This API is interesting is it possible to call onChange without any change? So for example in the color picker when the popovers close and we know that we will not apply additional color changes we would call onChange to move the focus back to the rich text as the inline link does.

this is just what I was looking for, it works well. Thanks a lot for all your hard work @ellatrix @jorgefilipecosta

jorgefilipecosta · 2019-09-27T13:57:06Z

Hi @ellatrix, I found no issues with the color picker from "advanced rich text" and with the color picker being implemented in #16014. Nice work 👍

Also now I see that for any button in the collapsed menu, focus won't be set back to rich text, but to the toggle button. That's because we look at the last focussed element.

Another side effect of this issue is that if we apply a code format and then a bold format, when we click the bold button the focus moves to the more richtext controls button and the tooltip becomes visible.

The only fix I think it to pass the rich text element to RichTextToolbarButton.

This idea seems like a possible path; maybe a reference can be passed using context, so users of RichTextToolbarButton are not aware of that. Any undesirable side effects of following this path?

ellatrix · 2019-09-27T14:25:31Z

Thanks again for testing. Yeah the way I implemented it in the button is flawed. Looking at the previous active element is not good, because in case of the drop down buttons it would be the toggle button. Thinking more about it, I actually think that we shouldn’t implement it at the button level at all... we’re assuming that the button will apply a format. A lot of buttons might not, and the core inline image button is a perfect example. So if we can’t do that? What’s left? We can track keyboard and mouse events from the moment the rich text element blurs. E.g. if there’s only been clicks, we set focus to rich text. But I’m not sure it this works either... the color panel is also just clicks. So maybe after only a single click? That again leaves out the drop down buttons... So... I really don’t know how we can only move focus to rich text when **clicking** a **RichTextButton** that does **not apply any formatting**. Perhaps we should leave this out and never return focus unless explicitly requested? The only drawback is that, after clicking a button, you have to click the text again to continue typing. Not great I guess. I’ll think a bit more about it.

…

On Fri, 27 Sep 2019 at 16:57, Jorge Costa ***@***.***> wrote: Hi @ellatrix <https://github.com/ellatrix>, I found no issues with the color picker from "advanced rich text" and with the color picker being implemented in #16014 <#16014>. Nice work 👍 Also now I see that for any button in the collapsed menu, focus won't be set back to rich text, but to the toggle button. That's because we look at the last focussed element. Another side effect of this issue is that if we apply a code format and then a bold format, when we click the bold button the focus moves to the more richtext controls button and the tooltip becomes visible. The only fix I think it to pass the rich text element to RichTextToolbarButton. This idea seems like a possible path; maybe a reference can be passed using context, so users of RichTextToolbarButton are not aware of that. Any undesirable side effects of following this path? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17617?email_source=notifications&email_token=ABD6B22TOQG5STGE6SE5XE3QLYGMHA5CNFSM4I25B772YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7Y7INY#issuecomment-535950391>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD6B26RGQBEA3N5GYHINVLQLYGMHANCNFSM4I25B77Q> .

jorgefilipecosta · 2019-09-27T15:01:24Z

Looking at the previous active element is not good, because in case
of the drop down buttons it would be the toggle button.

What if we never set the toggle button as the previous active element? When the more RichText Controls is the last focused moment we behave as we do if the last focused element was the richtext.

paaljoachim · 2019-11-10T17:18:15Z

Hey Ella @ellatrix How is this PR coming along?

It would be great to get this merged as the work on #16014 and #8171 will be able to continue.

Thanks!

ellatrix · 2020-01-09T21:51:25Z

New PR at #19536.

RichText: return focus after setting selection

f69af55

ellatrix requested review from daniloercoli, etoledom, jorgefilipecosta and SergioEstevao as code owners September 26, 2019 17:44

Fix rich text e2e tests

1ab4854

ellatrix requested review from ajitbohra, gziolo, nerrad, ntwb and talldan as code owners September 26, 2019 18:25

ellatrix added 6 commits September 26, 2019 21:30

Fix list e2e tests

483735b

Revert "Fix rich text e2e tests"

92ed806

This reverts commit 1ab4854.

Fix some rich text e2e tests

7a1b814

Only reset selection on focus if previously not selected

f31d816

Fix annotation e2e tests

fc138bf

Allow focus to be set through onChange

032d0dd

ellatrix added the [Package] Rich text /packages/rich-text label Sep 27, 2019

ellatrix commented Sep 27, 2019

View reviewed changes

Set focus back to rich text after mere button click

9de7520

ellatrix force-pushed the try/rich-text-no-focus branch from 71d4b05 to 9de7520 Compare September 27, 2019 10:36

ellatrix added the [Type] Bug An existing feature does not function as intended label Sep 27, 2019

ellatrix changed the title ~~RichText: return focus after setting selection~~ RichText: restore focus after setting selection Sep 27, 2019

jorgefilipecosta reviewed Sep 27, 2019

View reviewed changes

Ignore focus when applying selection

8468062

jorgefilipecosta reviewed Sep 27, 2019

View reviewed changes

ellatrix added the [Status] In Progress Tracking issues with work in progress label Oct 8, 2019

youknowriad mentioned this pull request Nov 21, 2019

Different focus behavior when clicking the toolbar buttons #6336

Open

bfintal mentioned this pull request Nov 22, 2019

Text & Highlight button closes when selecting a color from the gradient picker gambitph/Stackable#414

Closed

ellatrix mentioned this pull request Jan 9, 2020

RichText: don't set focus when applying format #19536

Merged

6 tasks

ellatrix closed this Jan 9, 2020

ellatrix deleted the try/rich-text-no-focus branch January 9, 2020 21:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RichText: restore focus after setting selection #17617

RichText: restore focus after setting selection #17617

ellatrix commented Sep 26, 2019 •

edited

Loading

mcsf commented Sep 27, 2019

ellatrix commented Sep 27, 2019

ellatrix commented Sep 27, 2019

mcsf commented Sep 27, 2019

mcsf commented Sep 27, 2019

ellatrix commented Sep 27, 2019

ellatrix Sep 27, 2019

ellatrix commented Sep 27, 2019

jorgefilipecosta left a comment

ellatrix commented Sep 27, 2019

ellatrix commented Sep 27, 2019

jorgefilipecosta commented Sep 27, 2019

ellatrix commented Sep 27, 2019

ellatrix commented Sep 27, 2019

ellatrix commented Sep 27, 2019

jorgefilipecosta Sep 27, 2019

ciprianimike Jan 29, 2020

jorgefilipecosta commented Sep 27, 2019

ellatrix commented Sep 27, 2019 via email

jorgefilipecosta commented Sep 27, 2019

paaljoachim commented Nov 10, 2019

ellatrix commented Jan 9, 2020

RichText: restore focus after setting selection #17617

RichText: restore focus after setting selection #17617

Conversation

ellatrix commented Sep 26, 2019 • edited Loading

Description

How has this been tested?

Screenshots

Types of changes

Checklist:

mcsf commented Sep 27, 2019

ellatrix commented Sep 27, 2019

ellatrix commented Sep 27, 2019

mcsf commented Sep 27, 2019

mcsf commented Sep 27, 2019

ellatrix commented Sep 27, 2019

ellatrix Sep 27, 2019

Choose a reason for hiding this comment

ellatrix commented Sep 27, 2019

jorgefilipecosta left a comment

Choose a reason for hiding this comment

ellatrix commented Sep 27, 2019

ellatrix commented Sep 27, 2019

jorgefilipecosta commented Sep 27, 2019

ellatrix commented Sep 27, 2019

ellatrix commented Sep 27, 2019

ellatrix commented Sep 27, 2019

jorgefilipecosta Sep 27, 2019

Choose a reason for hiding this comment

ciprianimike Jan 29, 2020

Choose a reason for hiding this comment

jorgefilipecosta commented Sep 27, 2019

ellatrix commented Sep 27, 2019 via email

jorgefilipecosta commented Sep 27, 2019

paaljoachim commented Nov 10, 2019

ellatrix commented Jan 9, 2020

ellatrix commented Sep 26, 2019 •

edited

Loading