C-s and C-r doesn't always search the next or previous occurrence.

[4goodapp]

When I run ctrlf then run the command other-window C-x o , (to maybe do some editing), I have to run other-window C-x o again to get back to ctrlf.
I expect I can run C-s or C-r anytime, whether the point is in the mini buffer or in the main buffer.

CTRLF takes the basic idea of Isearch, together with most of its keybindings, but emulates the more reliable user experience of web browser text search. For example: all editing commands can be used during a search as usual; C-g always has the effect of canceling the search; and C-s ALWAYS moves to the next candidate, with wraparound signaled by an overlay which indicates the current match index and the total number of matches (another UI paradigm borrowed from other programs).

[raxod502]

Fair enough. It looks like the current behavior is C-s and C-r have no effect when typed outside the minibuffer during an active search. I agree it would be an improvement to make them have the same effect as when point is in the minibuffer.

Until that is fixed, the best workaround I can think of is exiting the search with RET to perform editing, then resuming it with C-s C-s when editing is done. This is what I personally do.

[4goodapp]

Until that is fixed, the best workaround I can think of is exiting the search with RET to perform editing, then resuming it with C-s C-s when editing is done. This is what I personally do.

This workaround is fine for me as well.
C-s C-s bring back ctrlf with previous searched text.
Much easier than using other-window C-x o. Still I think ctrlf should after using other command command like other-window. Hopefully a fix won't be hard to implement.