WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
<
rdar://problem/45138739
>
Attachments
WIP patch
(38.18 KB, patch)
2018-12-25 21:51 PST
,
Wenson Hsieh
no flags
Details
Formatted Diff
Diff
WIP patch
(38.51 KB, patch)
2018-12-25 23:04 PST
,
Wenson Hsieh
no flags
Details
Formatted Diff
Diff
Patch
(44.79 KB, patch)
2018-12-26 12:50 PST
,
Wenson Hsieh
no flags
Details
Formatted Diff
Diff
Fix 32-bit macOS build
(44.85 KB, patch)
2018-12-26 13:55 PST
,
Wenson Hsieh
no flags
Details
Formatted Diff
Diff
Patch v2
(46.18 KB, patch)
2018-12-26 20:54 PST
,
Wenson Hsieh
no flags
Details
Formatted Diff
Diff
Patch v2 (fix macOS 10.12 builds)
(46.18 KB, patch)
2018-12-26 21:17 PST
,
Wenson Hsieh
thorton
: review+
Details
Formatted Diff
Diff
Rename FindInPage to Find
(45.92 KB, patch)
2019-01-02 19:08 PST
,
Wenson Hsieh
no flags
Details
Formatted Diff
Diff
Show Obsolete
(5)
View All
Add attachment
proposed patch, testcase, etc.
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
Created
attachment 358082
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug