RESOLVED FIXED 193034
Add support for using the current text selection as the find string on iOS
https://bugs.webkit.org/show_bug.cgi?id=193034
Summary Add support for using the current text selection as the find string on iOS
Wenson Hsieh
Reported 2018-12-25 21:43:48 PST
Attachments
WIP patch (38.18 KB, patch)
2018-12-25 21:51 PST, Wenson Hsieh
no flags
WIP patch (38.51 KB, patch)
2018-12-25 23:04 PST, Wenson Hsieh
no flags
Patch (44.79 KB, patch)
2018-12-26 12:50 PST, Wenson Hsieh
no flags
Fix 32-bit macOS build (44.85 KB, patch)
2018-12-26 13:55 PST, Wenson Hsieh
no flags
Patch v2 (46.18 KB, patch)
2018-12-26 20:54 PST, Wenson Hsieh
no flags
Patch v2 (fix macOS 10.12 builds) (46.18 KB, patch)
2018-12-26 21:17 PST, Wenson Hsieh
thorton: review+
Rename FindInPage to Find (45.92 KB, patch)
2019-01-02 19:08 PST, Wenson Hsieh
no flags
Wenson Hsieh
Comment 1 2018-12-25 21:51:56 PST
Created attachment 358074 [details] WIP patch
Wenson Hsieh
Comment 2 2018-12-25 23:04:13 PST
Created attachment 358076 [details] WIP patch
Wenson Hsieh
Comment 3 2018-12-26 12:50:44 PST
Wenson Hsieh
Comment 4 2018-12-26 13:55:57 PST
Created attachment 358085 [details] Fix 32-bit macOS build
Tim Horton
Comment 5 2018-12-26 14:44:34 PST
The name is ever so slightly weird to me; I think I would expect it to be the string you’re currently finding. Which it sometimes is, but not if you edit it in the UI or start a find some way other than Command-E?
Tim Horton
Comment 6 2018-12-26 15:14:35 PST
Comment on attachment 358085 [details] Fix 32-bit macOS build View in context: https://bugs.webkit.org/attachment.cgi?id=358085&action=review > Source/WebKit/UIProcess/Cocoa/FindInPageHelpers.mm:27 > +#import "FindInPageHelpers.h" "Helpers" is pretty unusual. Who usually talks to FindController? Maybe it should have a UI-side compatriot and these messages should go through there?
Wenson Hsieh
Comment 7 2018-12-26 16:53:47 PST
(In reply to Tim Horton from comment #5) > The name is ever so slightly weird to me; I think I would expect it to be > the string you’re currently finding. Which it sometimes is, but not if you > edit it in the UI or start a find some way other than Command-E? That makes sense! I think a better name for what I currently have here would be _initialStringForFindInPage; that being said, the purpose of this string is to stand in for the system-wide find pasteboard that's present on macOS but not iOS. To this end, it should probably behave like it does on macOS and either allow external clients to update it (e.g. whenever the user edits the find string), or teach WebKit find-in-page API to automatically update it when the find string changes. As such, I think _stringForFindInPage is actually the right name of the SPI we should expose — only, WebKit should also be updating it as the find string changes. What do you think about this?
Wenson Hsieh
Comment 8 2018-12-26 16:53:57 PST
Comment on attachment 358085 [details] Fix 32-bit macOS build View in context: https://bugs.webkit.org/attachment.cgi?id=358085&action=review >> Source/WebKit/UIProcess/Cocoa/FindInPageHelpers.mm:27 >> +#import "FindInPageHelpers.h" > > "Helpers" is pretty unusual. > > Who usually talks to FindController? Maybe it should have a UI-side compatriot and these messages should go through there? The common flow of information for find-in-page seems to be: (Views or other UI-side entities…) → WebPageProxy → (IPC) → WebPage → FindController. I opted for a "Helper"-file approach because _stringForFindInPage is global state shared throughout the process, so it didn't make sense to tie it to any of the usual suspects (i.e. WebPageProxy, or even something like a FindControllerProxy). We could introduce a FindControllerProxy and add these as static functions on it, but it seems odd to introduce a new FindControllerProxy and either (1) not actually create any instance of it because all we need are the static helpers, or (2) create and keep track of FindControllerProxy, but not actually use it for anything. Does this seem reasonable?
Tim Horton
Comment 9 2018-12-26 17:19:08 PST
Sounds good on both counts!
Wenson Hsieh
Comment 10 2018-12-26 20:54:50 PST
Created attachment 358097 [details] Patch v2
Wenson Hsieh
Comment 11 2018-12-26 21:17:57 PST
Created attachment 358099 [details] Patch v2 (fix macOS 10.12 builds)
Tim Horton
Comment 12 2019-01-02 11:17:55 PST
Comment on attachment 358099 [details] Patch v2 (fix macOS 10.12 builds) This patch introduces the first (and first bunch) of the use of the phrase "find in page" in actual code (vs. tests and changelog entries). Other SPI just calls it "find". I wonder if this patch should follow suit.
Wenson Hsieh
Comment 13 2019-01-02 11:32:21 PST
(In reply to Tim Horton from comment #12) > Comment on attachment 358099 [details] > Patch v2 (fix macOS 10.12 builds) > > This patch introduces the first (and first bunch) of the use of the phrase > "find in page" in actual code (vs. tests and changelog entries). Other SPI > just calls it "find". I wonder if this patch should follow suit. Good point! I'll follow suit and use "find" instead of "findInPage".
Wenson Hsieh
Comment 14 2019-01-02 19:08:31 PST
Created attachment 358242 [details] Rename FindInPage to Find
WebKit Commit Bot
Comment 15 2019-01-02 20:00:56 PST
Comment on attachment 358242 [details] Rename FindInPage to Find Clearing flags on attachment: 358242 Committed r239584: <https://trac.webkit.org/changeset/239584>
Note You need to log in before you can comment on or make changes to this bug.