On Aug 16, 2013, at 2:45 PM, Antonio Gomes <toniki...@webkit.org> wrote:
> Hi. > > Bug https://bugs.webkit.org/show_bug.cgi?id=119760 (Text dragging can > scroll overflow:hidden boxes) caught my attention to the following > situation: > > - imagine a page has an input field within a overflow:hidden <div>, > and user starts text selecting from the input field text by dragging > with the mouse. At some point it goes outside of the input boundary, > reaches the outer <div> boundary. By then, 'autoscroll' takes place > (see WebCore/page/AutoscrollController.cpp/h), and scrolls the outter > <div>. In my opinion, it should not happen, due to div's > overflow:hidden style. > > A natural solution for that could be hardening > RenderLayer::scrollRectToVisible, when its upwards recursion occurs; > so instead of picking the current layer parent, it picks the enclosing > scrollable layer instead. > > However, it seems acceptable that overflow:hidden div's RenderLayers > are scrollable in certain situations. Consider the case of > Element.scrollIntoView(), for example: as of now, WebKit scrolls an > container overflow:hidden div, if it is to bring an HTML element into > view. > > Both situations go through the same RenderLayer::scrollRectToVisible method. > > Introducing a ScrollSource parameter to indicate where the scrolling > action came from (user interaction or not), and relax or harden the > recursion criteria accordingly would not help, because it would break > autoscrolling within shadow DOM content (think of autoscrolling an > input's shadow DOM div). > > Do you guys have thoughts on that? How do other browsers behave in terms of drag-scrolling of overflow:hidden, revealing content in overflow:hidden, and programmatic scrolling of overflow:hidden? Simon _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev