Fix include end format when determining active formats #35882
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
getdave
added
[Feature] Rich Text
|
Size Change: +6 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
This comment has been minimized.
This comment has been minimized.
getdave
commented
Oct 25, 2021
getdave
commented
Oct 25, 2021
getdave
commented
Oct 25, 2021
getdave
changed the title
getdave
force-pushed
the
try/make-active-formats-include-formats-at-end
branch
2 times, most recently
from
49c12bc to
ec05371
Compare
getdave
force-pushed
the
try/make-active-formats-include-formats-at-end
branch
from
ec05371 to
37c259c
Compare
getdave
changed the title
Merged
7 tasks
|
No longer pursing this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR attempts to fix edge cases surrounding creation of link formats.
When a format is active and you make a non-collapsed selection starting within the format and moving to the left then the format becomes inactive as soon as the selection moves beyond the start of the format boundary (ie: on the left hand side).
Here's a video showing that:
Screen.Capture.on.2021-10-22.at.15-19-34.mp4
This is because the code that controls the
isActivestate of the Link UI relies ongetActiveFormatswhich only considers the start index (left hand side) of the formats when looking for active formats.In addition, if you create two adjacent links then making a selection in either direction (left to right or right to left) the link at the
startindex always takes presedence. This causes situations whereby the link you "began" your selection on might be superceeded by another unrelated link.Here's a video showing that:
Screen.Capture.on.2021-10-25.at.15-19-10.mp4
The result of all this is that it's very easy to achieve undesirable results such as creating links ontop of other existing links or getting the UI into a state where you're no longer sure which link is selected.
This PR does 3 things to fix this:
getActiveFormats. Thus as long as either start or end of the selection are within the format the format remains active.core/linkformats only:The bottom line: if any part of the selection moves outside the link format boundary or the link formats at either end don't match exactly then we no longer activate the Link UI.
Here's the fixed version (which is as per this PR)
Screen.Capture.on.2021-10-25.at.15-20-14.mp4
How has this been tested?
Screenshots
Types of changes
Checklist:
*.native.jsfiles for terms that need renaming or removal).