AppFlowy-IO/AppFlowy

Fork 0

mirror of https://github.com/AppFlowy-IO/AppFlowy.git synced 2026-03-24 12:56:59 +00:00

[GH-ISSUE #5491] [Bug] Search is not working properly and destructing the text #2443

New issue

Closed

opened 2026-03-23 21:22:24 +00:00 by mirror · 4 comments

mirror commented

2026-03-23 21:22:24 +00:00

Owner

Originally created by @unbreakabl3 on GitHub (Jun 7, 2024).
Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/5491

Originally assigned to: @MayurSMahajan on GitHub.

Bug Description

When searching for a word and looping with Enter, the following is happening each click on Enter

https://github.com/AppFlowy-IO/AppFlowy/assets/13556249/2c86bc55-5988-4c75-a690-4bec5de1f677

When searching for a word and looping with arrows, the following is happening each click on arrow. Once the jump down happened, there is no way to go back.

https://github.com/AppFlowy-IO/AppFlowy/assets/13556249/bff27f9f-2864-4bed-b199-dd606ac62b70

How to Reproduce

Try to find some word, which appears more than once.

Expected Behavior

Looping across should happen and formatting of the text should not be done.

Operating System

MacOS 14.5

AppFlowy Version(s)

0.5.9

Screenshots

No response

Additional Context

No response

Originally created by @unbreakabl3 on GitHub (Jun 7, 2024). Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/5491 Originally assigned to: @MayurSMahajan on GitHub. ### Bug Description When searching for a word and looping with Enter, the following is happening each click on Enter https://github.com/AppFlowy-IO/AppFlowy/assets/13556249/2c86bc55-5988-4c75-a690-4bec5de1f677 When searching for a word and looping with arrows, the following is happening each click on arrow. Once the jump down happened, there is no way to go back. https://github.com/AppFlowy-IO/AppFlowy/assets/13556249/bff27f9f-2864-4bed-b199-dd606ac62b70 ### How to Reproduce Try to find some word, which appears more than once. ### Expected Behavior Looping across should happen and formatting of the text should not be done. ### Operating System MacOS 14.5 ### AppFlowy Version(s) 0.5.9 ### Screenshots _No response_ ### Additional Context _No response_

mirror closed this issue

2026-03-23 21:22:24 +00:00

mirror commented

2026-03-23 21:22:25 +00:00

Author

Owner

@Xazin commented on GitHub (Jun 9, 2024):

Since this was originally implemented by you @MayurSMahajan , I wonder if you want to also work on improvements and bug fixes for inline document search?

@Xazin commented on GitHub (Jun 9, 2024): Since this was originally implemented by you @MayurSMahajan , I wonder if you want to also work on improvements and bug fixes for inline document search?

mirror commented

2026-03-23 21:22:25 +00:00

Author

Owner

@MayurSMahajan commented on GitHub (Jun 10, 2024):

I can take a look at this one, but if something is priority, I request the team to handle it due to my time constraints.

@MayurSMahajan commented on GitHub (Jun 10, 2024): I can take a look at this one, but if something is priority, I request the team to handle it due to my time constraints.

mirror commented

2026-03-23 21:22:25 +00:00

Author

Owner

@MayurSMahajan commented on GitHub (Jun 13, 2024):

Hey @Xazin,
So after observing this issue, I have noticed two things:

For scroll freeze: There is a jumpTo() method call which causes the editor to shift all content down and get frozen there.
For selected text getting replaced after pressing enter: This only happens when the focus is not on the Find Text Input field. Thus the Enter key event causes the editor to replace the selected text, rather than navigating to the next match.

I have solved the first part of the issue by removing the jumpTo() call, since anyway making a new selection causes the editor to scroll to the selected content. I will create a PR for this in the AppFlowyEditor repo.

I need some help tackling the second part.
Approach 1: I tried implementing Shortcuts, Actions, and Intent to listen to the Enter key event on the FindReplace widget to kind of intercept the Enter key event before it is handled by the Editor itself, which as expected, deletes the selected content. But I am not able to do it.
Approach 2: I wrapped the FindReplace widget with KeyboardEventListener, this too causes the editor to take over and insert a newline after handling the onKeyEvent.

Can you give me a hint for deciding a strategy towards stopping the editor from deleting the content?
Anyway, I will continue brainstorming, just updating everyone on the current progress of the issue.

@MayurSMahajan commented on GitHub (Jun 13, 2024): Hey @Xazin, So after observing this issue, I have noticed two things: 1. For scroll freeze: There is a `jumpTo()` method call which causes the editor to shift all content down and get frozen there. 2. For selected text getting replaced after pressing enter: This only happens when the focus is not on the Find Text Input field. Thus the Enter key event causes the editor to replace the selected text, rather than navigating to the next match. I have solved the first part of the issue by removing the `jumpTo()` call, since anyway making a new selection causes the editor to scroll to the selected content. I will create a PR for this in the AppFlowyEditor repo. I need some help tackling the second part. Approach 1: I tried implementing Shortcuts, Actions, and Intent to listen to the `Enter` key event on the `FindReplace` widget to kind of intercept the `Enter` key event before it is handled by the Editor itself, which as expected, deletes the selected content. But I am not able to do it. Approach 2: I wrapped the `FindReplace` widget with `KeyboardEventListener`, this too causes the editor to take over and insert a newline after handling the `onKeyEvent`. Can you give me a hint for deciding a strategy towards stopping the editor from deleting the content? Anyway, I will continue brainstorming, just updating everyone on the current progress of the issue.

mirror commented

2026-03-23 21:22:26 +00:00

Author

Owner

@annieappflowy commented on GitHub (Oct 1, 2024):

Fixed

@annieappflowy commented on GitHub (Oct 1, 2024): Fixed

mirror referenced this issue

2026-03-23 22:17:50 +00:00

[PR #2443] [MERGED] fix: number format #5234