Consider a page with the following markup: <!DOCTYPE html> <html> <body> <input> <iframe width="500" height="500" srcdoc="<textarea>Hello</textarea>"></iframe> </body> </html> If you set the set the insertion point to be before the 'H' in the textarea and -requestDocumentContext for character rects then the returned rects are in the coordinate system of the framed document, but they should be in root view coordinates.
<rdar://problem/60840261>
Created attachment 394407 [details] Patch and tests
Comment on attachment 394407 [details] Patch and tests View in context: https://bugs.webkit.org/attachment.cgi?id=394407&action=review > Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:4254 > + rects.append({ currentRange->ownerDocument().view()->contentsToRootView(absoluteBoundingBox), { offsetSoFar++, stride } }); What guarantees that view() is non-null here?
Comment on attachment 394407 [details] Patch and tests View in context: https://bugs.webkit.org/attachment.cgi?id=394407&action=review Thanks for the review, Wenson. >> Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:4254 >> + rects.append({ currentRange->ownerDocument().view()->contentsToRootView(absoluteBoundingBox), { offsetSoFar++, stride } }); > > What guarantees that view() is non-null here? How can it be null here? The owner document for these ranges has to be the document in the focused frame since the range is constructed with respect to the frame's selection. If focusedOrMainFrame() returns a frame without a view then it must the main frame because detaching a focused frame, which is what had to happen for its view to be nullified, defocuses it. And the main frame is the focused frame of last resort. So, that means it only the main frame can be returned and possibly not have a view. But that cannot happen either because there is nothing that this function does that could cause that... oh, I misspoke, layout. That's an existing bug in this function not related to this patch...Anyway, I'll take out a ref for the frame view of the focused frame at the top of this function.
Comment on attachment 394407 [details] Patch and tests View in context: https://bugs.webkit.org/attachment.cgi?id=394407&action=review >>> Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:4254 >>> + rects.append({ currentRange->ownerDocument().view()->contentsToRootView(absoluteBoundingBox), { offsetSoFar++, stride } }); >> >> What guarantees that view() is non-null here? > > How can it be null here? The owner document for these ranges has to be the document in the focused frame since the range is constructed with respect to the frame's selection. If focusedOrMainFrame() returns a frame without a view then it must the main frame because detaching a focused frame, which is what had to happen for its view to be nullified, defocuses it. And the main frame is the focused frame of last resort. So, that means it only the main frame can be returned and possibly not have a view. But that cannot happen either because there is nothing that this function does that could cause that... oh, I misspoke, layout. That's an existing bug in this function not related to this patch...Anyway, I'll take out a ref for the frame view of the focused frame at the top of this function. Will fix this in bug #209506.
Comment on attachment 394407 [details] Patch and tests Clearing flags on attachment: 394407 Committed r258945: <https://trac.webkit.org/changeset/258945>
All reviewed patches have been landed. Closing bug.
Dang it, I forgot this patch depends on another bug fix I didn't post yet to make selecting position at point work in <iframes>. That's why the test fails. I'm going to disable the test temporarily for tonight. Tomorrow I will have the patch to fix it....
I'm just going to revert this change for the moment.
Reverted r258945 for reason: Revert change that broke API tests while I investigate offline. Committed r258974: <https://trac.webkit.org/changeset/258974>
Comment on attachment 394407 [details] Patch and tests View in context: https://bugs.webkit.org/attachment.cgi?id=394407&action=review > Tools/TestWebKitAPI/Tests/WebKitCocoa/DocumentEditingContext.mm:520 > + [webView synchronouslyLoadHTMLString:applyAhemStyle([NSString stringWithFormat:@"<iframe srcdoc=\"%@\" style='position: absolute; left: 1em; top: 1em; border: none'></iframe>", applyAhemStyle(@"<textarea id='test' style='padding: 0'>The quick brown fox jumps over the lazy dog.</textarea><script>let textarea = document.querySelector('iframe').contentDocument.getElementById('test'); textarea.focus(); textarea.setSelectionRange(0, 0); /* Place caret at the beginning of the field. */</script>")])]; Here's the bug that led to the test failure.... let textarea = document.querySelector('iframe').contentDocument.getElementById('test'); should be: let textarea = document.getElementById('test');
Created attachment 394546 [details] To Land
Committed r259013: <https://trac.webkit.org/changeset/259013>