Correction to layoutOverflowRect in case of direction:rtl

Source/core/rendering/RenderBox.cpp

 /*
  * Copyright (C) 1999 Lars Knoll (knoll@kde.org)
  *           (C) 1999 Antti Koivisto (koivisto@kde.org)
  *           (C) 2005 Allan Sandfeld Jensen (kde@carewolf.com)
  *           (C) 2005, 2006 Samuel Weinig (sam.weinig@gmail.com)
  * Copyright (C) 2005, 2006, 2007, 2008, 2009, 2010 Apple Inc. All rights reserved.
  * Copyright (C) 2013 Adobe Systems Incorporated. All rights reserved.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
@@ skipping 4544 matching lines @@
 
 LayoutRect RenderBox::noOverflowRect() const
 {
     // Because of the special coodinate system used for overflow rectangles and many other
     // rectangles (not quite logical, not quite physical), we need to flip the block progression
     // coordinate in vertical-rl and horizontal-bt writing modes. In other words, the rectangle
     // returned is physical, except for the block direction progression coordinate (y in horizontal
     // writing modes, x in vertical writing modes), which is always "logical top". Apart from the
     // flipping, this method does the same as clientBoxRect().
 
-    LayoutUnit left = borderLeft();
+    LayoutUnit left = borderLeft() + (style()->shouldPlaceBlockDirectionScrollbarOnLogicalLeft() ? verticalScrollbarWidth() : 0);
     LayoutUnit top = borderTop();
     LayoutUnit right = borderRight();
     LayoutUnit bottom = borderBottom();
     LayoutRect rect(left, top, width() - left - right, height() - top - bottom);
     flipForWritingMode(rect);
     // Subtract space occupied by scrollbars. Order is important here: first flip, then subtract
     // scrollbars. This may seem backwards and weird, since one would think that a horizontal
     // scrollbar at the physical bottom in horizontal-bt ought to be at the logical top (physical
     // bottom), between the logical top (physical bottom) border and the logical top (physical
     // bottom) padding. But this is how the rest of the code expects us to behave. This is highly
     // related to https://bugs.webkit.org/show_bug.cgi?id=76129
     // FIXME: when the above mentioned bug is fixed, it should hopefully be possible to call
     // clientBoxRect() or paddingBoxRect() in this method, rather than fiddling with the edges on
     // our own.
-    rect.contract(verticalScrollbarWidth(), horizontalScrollbarHeight());
+    if (style()->shouldPlaceBlockDirectionScrollbarOnLogicalLeft())
+        rect.contract(0, horizontalScrollbarHeight());
+    else
+        rect.contract(verticalScrollbarWidth(), horizontalScrollbarHeight());
     return rect;
 }
 
 LayoutRect RenderBox::overflowRectForPaintRejection() const
 {
     LayoutRect overflowRect = visualOverflowRect();
     if (!m_overflow || !usesCompositedScrolling())
         return overflowRect;
 
     overflowRect.unite(layoutOverflowRect());
@@ skipping 174 matching lines @@
         return 0;
 
     if (!layoutState && !flowThreadContainingBlock())
         return 0;
 
     RenderBlock* containerBlock = containingBlock();
     return containerBlock->offsetFromLogicalTopOfFirstPage() + logicalTop();
 }
 
 } // namespace WebCore