Description
There are times when the search bar cannot receive focus (by tapping on it), meaning you cannot input search terms or interact with it in any way.
To Reproduce
Kill FSNotes
Load FSNotes
Slide the notes list down so the search bar appears at the top
Tap on the search bar
Expected outcome:
The search bar receives focus, and the on screen keyboard appears so you can input search terms
Actual outcome:
Nothing, user is unable to interact with the search bar
Expected behavior
The search bar receives focus, and the on screen keyboard appears so you can input search terms
FSNotes version
7.3.1 build 336
macOS/iOS version
iOS 18.7.9, iPhone XR
Additional context
Various interactions with other UI elements will enable the search bar to be interacted with. For example, following on from the above reproduction steps, if you tap on the settings icon then tap the "< Notes" back link, you will see the notes list show, and then the search bar pops on screen. You can now interact with the search bar as expected.
If however, for example, following on from the above reproduction steps, instead of tapping on the settings icon, you tap the side bar icon (icon to the left of the settings icon), you still cannot interact with the search bar. In this situation, the search bar and list stay visible on screen so don't need to be redrawn.
Speculation on possible causes:
This bug might be caused by an incorrect initial Z-order so while it becomes visible when sliding the notes list down, other UI elements are in fact on top of it, or some similar equivalent regarding how the search bar shows when sliding the notes list down. Perhaps there is a bug in the way the heights and positions are calculated when the notes list is slid down and the search bar appears (and UI elements are still on top of it), since there is no user slide action that occurs when exiting from the settings view.
It appears what the way in which the notes list and search bar are drawn on screen when exiting from the settings view results in the correct layout (since you can interact with the search bar), and this is slightly different in some way from when the user slides the notes list down to reveal the search bar (which cannot be interacted with). It's possible this bug doesn't exist on all models or the simulator, in which case view port and UI widget height calculations or various NS Constraints might be something to look at.
Description
There are times when the search bar cannot receive focus (by tapping on it), meaning you cannot input search terms or interact with it in any way.
To Reproduce
Kill FSNotes
Load FSNotes
Slide the notes list down so the search bar appears at the top
Tap on the search bar
Expected outcome:
The search bar receives focus, and the on screen keyboard appears so you can input search terms
Actual outcome:
Nothing, user is unable to interact with the search bar
Expected behavior
The search bar receives focus, and the on screen keyboard appears so you can input search terms
FSNotes version
7.3.1 build 336
macOS/iOS version
iOS 18.7.9, iPhone XR
Additional context
Various interactions with other UI elements will enable the search bar to be interacted with. For example, following on from the above reproduction steps, if you tap on the settings icon then tap the "< Notes" back link, you will see the notes list show, and then the search bar pops on screen. You can now interact with the search bar as expected.
If however, for example, following on from the above reproduction steps, instead of tapping on the settings icon, you tap the side bar icon (icon to the left of the settings icon), you still cannot interact with the search bar. In this situation, the search bar and list stay visible on screen so don't need to be redrawn.
Speculation on possible causes:
This bug might be caused by an incorrect initial Z-order so while it becomes visible when sliding the notes list down, other UI elements are in fact on top of it, or some similar equivalent regarding how the search bar shows when sliding the notes list down. Perhaps there is a bug in the way the heights and positions are calculated when the notes list is slid down and the search bar appears (and UI elements are still on top of it), since there is no user slide action that occurs when exiting from the settings view.
It appears what the way in which the notes list and search bar are drawn on screen when exiting from the settings view results in the correct layout (since you can interact with the search bar), and this is slightly different in some way from when the user slides the notes list down to reveal the search bar (which cannot be interacted with). It's possible this bug doesn't exist on all models or the simulator, in which case view port and UI widget height calculations or various NS Constraints might be something to look at.