Created attachment 226300 [details] Patch

Comment on attachment 226300 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=226300&action=review r- because of the padding box issue. Also, don't forget about the CLs. > Source/WebCore/rendering/RenderNamedFlowFragment.cpp:258 > + ASSERT(&fragmentContainer() == o); We should also assert o == container() as the other implementations of offsetFromContainer do. > Source/WebCore/rendering/RenderNamedFlowThread.cpp:381 > + IntRect fragmentAbsoluteRect(roundedIntPoint(fragmentContainer.localToAbsolute()), roundedIntSize(fragmentContainer.paddingBoxRect().size())); I'm not sure this is correct. For example, if you have a region chain with two regions. The first region: padding-bottom: 100px, overflow: hidden. The second region: margin-top: -100px, padding: 0px, overflow: hidden. For a point found above the padding of the first region, fragmentFromAbsolutePointAndBox() will return the first region, not the second one, right? We should use the visualOverflow rectangles in each region to correctly determine this. Also, in the stacking order of the region layers.

Comment on attachment 226300 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=226300&action=review >> Source/WebCore/rendering/RenderNamedFlowFragment.cpp:258 >> + ASSERT(&fragmentContainer() == o); > > We should also assert o == container() as the other implementations of offsetFromContainer do. OK. >> Source/WebCore/rendering/RenderNamedFlowThread.cpp:381 >> + IntRect fragmentAbsoluteRect(roundedIntPoint(fragmentContainer.localToAbsolute()), roundedIntSize(fragmentContainer.paddingBoxRect().size())); > > I'm not sure this is correct. For example, if you have a region chain with two regions. > The first region: padding-bottom: 100px, overflow: hidden. > The second region: margin-top: -100px, padding: 0px, overflow: hidden. > > For a point found above the padding of the first region, fragmentFromAbsolutePointAndBox() will return the first region, not the second one, right? We should use the visualOverflow rectangles in each region to correctly determine this. Also, in the stacking order of the region layers. This is part of the old code, it's not code added by this patch. Also, a flowed scrollable element will always have a range of just one region, which means we will not encounter the situation you describe. If this situation changes, a better solution should be found for this.

Created attachment 226302 [details] Patch

Comment on attachment 226302 [details] Patch r=me. Please add a bug to track either rename the function with something like "...ForScrolling" or, even better, file a bug to implement this at a layer level. Right now you won't get a positive result if you scroll over the overflow of a region, thus not scrolling the region container as it should happen.

Comment on attachment 226302 [details] Patch Clearing flags on attachment: 226302 Committed r165377: <http://trac.webkit.org/changeset/165377>

All reviewed patches have been landed. Closing bug.