<div><br></div>Thanks for a super quick response Darin. One followup question:<div><br></div><div>&gt;†The find code in markAllMatchesForText needs to not consider matches that cross the boundary between the inside of an edit field and the rest of the document.</div>
<div><br></div><div>Fair enough. I can see why it should ignore those matches, but if you look at the details for the bug (<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><a href="https://bugs.webkit.org/show_bug.cgi?id=25868" target="_blank" style="color: rgb(42, 93, 176); ">https://bugs.webkit.org/show_bug.cgi?id=25868</a><span class="Apple-style-span" style="border-collapse: separate; font-family: arial; font-size: small; ">) it states that the markAllMatchesForText function not only ignores the match but it also stops looking for more matches...</span></span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><span class="Apple-style-span" style="border-collapse: separate; font-family: arial; font-size: small; "><br>
</span></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><span class="Apple-style-span" style="border-collapse: separate; font-family: arial; font-size: small; ">I assume that&#39;s not expected?</span></span></div>
<div><br><br><div class="gmail_quote">On Fri, Apr 9, 2010 at 10:58, Darin Adler <span dir="ltr">&lt;<a href="mailto:darin@apple.com">darin@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Apr 9, 2010, at 10:52 AM, Finnur Thorarinsson wrote:<br>
<br>
&gt; I need a WebKit &quot;Ranger&quot; for this question:<br>
&gt;<br>
&gt; Imagine I have the word &quot;Foo&quot; inside an edit field (input type=text value=&quot;Foo&quot;) and the word &quot;bar&quot; outside of it, like so: [Foo]bar<br>
&gt;<br>
&gt; If I try to create a Range of the text Foobar, the range will get collapsed.<br>
&gt;<br>
&gt; It collapses because Range::setEnd has a |start| inside the shadow tree and an |end| outside of it. Specifically, setEnd walks up the parent chain for both |start| and |end| (to see if they share the same root container), but doesn&#39;t reach the top for |start| because while walking up the parent list it stops on a shadow node (TextControlInnerTextElement), which has only a shadow parent.<br>

&gt;<br>
&gt; Is this expected? Is this a bug? Is the right fix to have it walk up the shadow parent for shadow nodes?<br>
&gt;<br>
&gt; Best regards,<br>
&gt; Finnur<br>
&gt;<br>
&gt; PS. I believe this is the root cause for <a href="https://bugs.webkit.org/show_bug.cgi?id=25868" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=25868</a>, which was a regression caused by the fix for <a href="https://bugs.webkit.org/show_bug.cgi?id=7023" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=7023</a>.<br>

<br>
</div></div>Itís expected behavior.<br>
<br>
A selection needs to be either entirely inside an edit field, or outside the edit field. We donít support selections that start partway through an edit field and then continue out to the outside document.<br>
<br>
>From the DOM APIís point of view, selections inside an edit field arenít really selections at all. The DOM nodes within the shadow DOM tree should never be exposed to JavaScript in a webpage.<br>
<br>
The find code in markAllMatchesForText needs to not consider matches that cross the boundary between the inside of an edit field and the rest of the document.<br>
<font color="#888888"><br>
 † †-- Darin<br>
<br>
</font></blockquote></div><br></div>