40361 2010-06-09 07:04:31 -0700 Frame::findString does nothing on pages that prevent selection 2013-05-22 15:52:09 -0700 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) All All NEW http://m.cnn.com InRadar P2 Normal --- 1 mifenton webkit-unassigned ap darin enrica mitz mkosiba rniwa sullivan oldest_to_newest 235769 0 mifenton 2010-06-09 07:04:31 -0700 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. 235971 1 ap 2010-06-09 13:35:03 -0700 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. 235972 2 ap 2010-06-09 13:35:30 -0700 <rdar://problem/8076589> 502004 3 mkosiba 2011-11-14 09:35:06 -0800 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. 502084 4 rniwa 2011-11-14 10:54:40 -0800 I think we should fix findString to handle this case as well. 502350 5 darin 2011-11-14 15:02:41 -0800 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. 502794 6 mkosiba 2011-11-15 03:53:47 -0800 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. 892581 7 rniwa 2013-05-22 15:52:09 -0700 editing/text-iterator/findString-selection-disabled.html passes now. I'm not sure if we should also close this bug or not.