twingeofregret Thanks for checking it out!
The browser address bar is optimized for going to an address.
I can agree that up to about 10 years ago this was the case. Then a change happened with omnibar concept introduced by Firefox. Now all of the sudden the main purpose of that long input bar in the browser was to search!
Indeed most people use this nowadays to search. They mainly search with the search engine, but also the omnibar allows the user to search currently open tabs, history and bookmarks. Indeed, searching constitues most of the usage of the omnibar today.
Searching for content on the page is just another extension of the search capability that is both context and tab aware. This is the reason that when I first saw this feature implemented in this way in Kaktus, it clicked with me. Separating the search on page from omnibar would feel like separating search engine box from omnibar - unnecessary.
you need to physically "close" the find in page to get back to the main address bar.
But, interaction itself is as quick or quicker then with separate UI for find on page.
The only thing I need to be able to edit my URL is press ESC. Considering I just typed cmd f, means my hands are on the keyboard already.
With separate find UI, I have to either press cmd - l (harder than just ESC) or move my mouse to click the address bar.
Integrated find on page is easier in this sense too, specially because "ESC" to cancel is already a known pattern for any type of search in omnibar. If I start searching for something, I press escape to go back to my URL.