[webkit-dev] Scrolling overflow:hidden boxes..
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? Cheers, --Antonio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Scrolling overflow:hidden boxes..
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
Re: [webkit-dev] Scrolling overflow:hidden boxes..
I did not test exhaustively (various different scenarios), but hopefully it is of help: - text selection drag-scrolling of overflow:hidden : http://jsfiddle.net/auk9S/8/ Safari/Chrome/Opera15: perform scroll Mozilla: does not perform scroll Opera12 (pre-blink): does not perform scroll - programmatic scrolling of overflow:hidden (via element.scrollIntoView): LayoutTests/fast/transforms/scrollIntoView-transformed.html Sarafi/Chrome/Opera15: perform scroll Mozilla: perform scroll Opera12 (pre-blink): perform scroll On Fri, Aug 16, 2013 at 6:26 PM, Simon Fraser simon.fra...@apple.com wrote: 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
