-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
RichText: fix RTL keyboard interactions #15496
Conversation
Just tested the RichText interactions:
But when it comes to cross-block interactions (WritingFlow?), both arrow keys and backspace/del are still broken:
|
@youknowriad I think I fixed the remaining issues. Something else I'm seeing is e.g. left/right keys not working correctly in toolbars. Not sure if I should fix here. |
@youknowriad How is it looking now? :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issues seem fixed to me. Thank @ellatrix
We should explore how to e2e test RTL languages too
Whooo :) Working on the e2e tests now, but it's not easy 😅 |
@ellatrix I actually just noticed a bug:
Instead of removing the "br", it tries to merge with the previous block |
Added e2e tests. Looking at the remaining issue now. |
a0cb3d9
to
b3d4ba6
Compare
All e2e test pass for me locally. Not sure what is going on. @youknowriad I think everything should work fine now, including the edge case you mentioned. |
c742d95
to
33ed7f3
Compare
There are some failing tests, I don't know if it's legit. |
Yeah, fixed a few already. There's one final failing annotation test. |
77b1106
to
de2541e
Compare
e2b12c8
to
fc6f293
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just tested this again. In terms of behavior, it still seems to work as intended.
@@ -378,7 +368,20 @@ export class RichText extends Component { | |||
} | |||
|
|||
this.recalculateBoundaryStyle(); | |||
this.onSelectionChange(); | |||
|
|||
// We know for certain that on focus, the old selection is invalid. It |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it's not worth worrying about, but: There are cases where a focus
event occurs, but the selection remains the same. Notably, when the tab loses or regains focus (becomes the active tab again). I notice it most when debugging, to add a breakpoint in a code path which triggers on a change to state. The act of focusing DevTools and changing back to the window is enough to cause a change in state, so the breakpoint will fire.
Perhaps it's not a big deal, but could we:
- Avoid calling
onSelectionChange
if the selection indices are the same? Perhaps also avoidsetState
as well. - Update the reducer for
selectionStart
andselectionEnd
to avoid creating new object references if the updated offsets are the same as the current state value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aduth onSelectionChange
already avoids setting state if the selection is the same. I guess the problem here is that it's set to undefined
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aduth
onSelectionChange
already avoids setting state if the selection is the same
Where does this happen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here:
gutenberg/packages/rich-text/src/component/index.js
Lines 537 to 545 in 5957797
if ( start === value.start && end === value.end ) { | |
// Sometimes the browser may set the selection on the placeholder | |
// element, in which case the caret is not visible. We need to set | |
// the caret before the placeholder if that's the case. | |
if ( value.text.length === 0 && start === 0 ) { | |
fixPlaceholderSelection(); | |
} | |
return; |
Description
Fixes https://core.trac.wordpress.org/ticket/47180.
Fixes arrow left/right navigation and backspace/delete at the edges of rich text areas.
Fixes some boundary issues #15466 (review).
RichText
, I removed some left/right key handling. We should let the browser do its thing and only interfere at boundaries.isHorizontalEdge
, the horizontal checks need to reversed in RTL.WritingFlow
, the left/right arrow key handling needs to be reversed as right means previous and left means next.master
.Any other broken interactions?
How has this been tested?
Screenshots
Types of changes
Checklist:
closes #15553 and closes #15364