[Webkit-unassigned] [Bug 186956] AX: [iOS] VoiceOver scroll position is jumpy in frames

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=186956

--- Comment #5 from Nan Wang <n_wang at apple.com> ---
(In reply to Simon Fraser (smfr) from comment #4)
> Comment on attachment 343409 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=343409&action=review
> 
> >>> Source/WebCore/platform/ScrollView.cpp:851
> >>> +        return convertToContainingView(contentsToView(rect));
> >> 
> >> This looks like it's duplicating what Frederic was trying to do in bug 182785. You need to be careful here; this change can affect both UIWebView and WKWebView on iOS, and you need to examine the callers to make sure you didn't break anything. Also bear in mind that we don't have good UIWebViewtest coverage.
> > 
> > I think that's a different issue since it's checking the window? 
> > contentsToContainingViewContents() is only being called in RenderLayer::scrollRectToVisible()
> > 
> > Do you mean I should check all the callers of RenderLayer::scrollRectToVisible()?
> 
> Actually I think you're papering over the issue that bug 182785 is trying to
> fix. We always want to take scroll offsets into account when converting
> rects (and, anyway, with frame flattening, iframe scroll offsets should
> always be zero). But ScrollView::windowToContents() breaks that assumption
> right now, and we're trying to fix it but ScrollView::windowToContents() has
> lots of callers and fixing it is hard.

Ok I see your concern regarding ScrollView::windowToContents(). But here we are only dealing with contentsToContainingViewContents() and RenderLayer::scrollRectToVisible() is the only caller. Do you think the fix is safe enough just for this particular case?
Are you saying that we should replace the delegatesScrolling() check to be something else that covers more cases? I'm not sure if I have enough knowledge about the scrolling concept. Can you point me to what other cases we were missing? I don't think I have enough context just from this particular bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180626/661cd088/attachment.html>