Bug 40361
| Summary: | Frame::findString does nothing on pages that prevent selection | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Mike Fenton <mifenton> |
| Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ap, darin, enrica, mitz, mkosiba, rniwa, sullivan |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://m.cnn.com | ||
Mike Fenton
On pages that prevent selection, such as m.cnn.com, any calls to Frame::findString fail to mark any matches because the markers are tied directly to selection which is prevented.
An alternate method for marking found text (perhaps using a document marker) should be used for all non-editable text.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
Testing Cmd+F behavior on this page:
Mac Safari 4.0.5: nothing is found.
Mac Safari 5: all matches are found, but current match isn't highlighted, and Cmd+G is broken.
Mac Safari 4.0.5 + ToT WebKit: Same as Safari 5.
Alexey Proskuryakov
<rdar://problem/8076589>
Martin Kosiba
You could use rangeOfString (which is what findString uses under the covers) as I've demonstrated here: https://bugs.webkit.org/show_bug.cgi?id=72281.
Ryosuke Niwa
I think we should fix findString to handle this case as well.
Darin Adler
Fixing Safari’s command-F behavior will be mostly Safari code changes. I don’t think this can be done as a pure WebKit fix.
Martin Kosiba
The most I can do is wrap up the "find and display results using markers" functionality to make the issue simpler to fix in other ports.
Ryosuke Niwa
editing/text-iterator/findString-selection-disabled.html passes now. I'm not sure if we should also close this bug or not.