Interesting, it looks like we position the layer incorrectly assuming there'll be space saved for scrollbars...

Actually this bug is unrelated to overlay scrollbars - it's the iframe border that we're failing to account for.

Here's a better repro:

$ content_shell --root-layer-scrolls --enable-prefer-compositing-to-lcd-text https://output.jsbin.com/mazutab/quiet

sataya.m, do you or someone on your team have time to look at this one?

Deleted: Screenshot from 2017-10-02 15:55:49.png 13.5 KB

	Screenshot from 2017-10-02 15:55:49.png 13.5 KB View Download

@Skobes, after the following changes, we can see the background at proper place.
Any pointers on what needs to be checked further?
+++ b/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp
@@ -2003,7 +2003,6 @@ bool PaintLayerScrollableArea::ComputeNeedsCompositedScrolling(
       !layer->CompositesWithTransform() && !layer->CompositesWithOpacity();
 
   if (!layer_has_been_composited &&
-      !layer->Compositor()->PreferCompositingToLCDTextEnabled() &&
       !background_supports_lcd_text) {
     if (layer->CompositesWithOpacity()) {
       non_composited_main_thread_scrolling_reasons_ |=
diff --git a/third_party/WebKit/Source/core/paint/compositing/CompositingReasonFinder.cpp b/third_party/WebKit/Source/core/paint/compositing/CompositingReasonFinder.cpp
index f2c6d25..837cf84 100644
--- a/third_party/WebKit/Source/core/paint/compositing/CompositingReasonFinder.cpp
+++ b/third_party/WebKit/Source/core/paint/compositing/CompositingReasonFinder.cpp
@@ -27,7 +27,7 @@ void CompositingReasonFinder::UpdateTriggers() {
 
   Settings& settings = layout_view_.GetDocument().GetPage()->GetSettings();
   if (settings.GetPreferCompositingToLCDTextEnabled()) {
-    compositing_triggers_ |= kScrollableInnerFrameTrigger;
+    //compositing_triggers_ |= kScrollableInnerFrameTrigger;
     compositing_triggers_ |= kOverflowScrollTrigger;
     compositing_triggers_ |= kViewportConstrainedPositionedTrigger;
   }

This tells us that the problem is specific to iframes with composited layers.

I suspect it's a problem with the positioning of these layers.  See for example CompositedLayerMapping::UpdateOverflowControlsHostLayerGeometry which determines the location of CLM::overflow_controls_host_layer_ (which contains the scrollbar layers).

To see the entire layer tree you can use <script>console.log(internals.layerTreeAsText(document, -1))</script>.  Also --show-composited-layer-borders will draw a highlight around every layer.

    host_layer_position.Move(-graphics_layer_->OffsetFromLayoutObject());

    overflow_controls_host_layer_->SetPosition(FloatPoint(host_layer_position));

host_layer_position is 0 x 0. It should be 20 x 20. as border is 20px;

graphics_layer_->OffsetFromLayoutObject() should return the offset properly when border is present for Iframe Document Layer.

overflowControlsHostLayer is picking up the location of the parent Graphics layer
whose location is 0 X 0. I guess we need to add border top, border left to the parent location 

on just adding host_layer_position.Move(20,20);

before   overflow_controls_host_layer_->SetPosition(FloatPoint(host_layer_position));

creates the scrollbars at correct position but still, the content of the iframe starts from 0 x 0. PFAI.

Deleted: issue.png 6.9 KB

	issue.png 6.9 KB View Download

I think we can try debugging CompositedLayerMapping::ComputeGraphicsLayerParentLocation where the border values are being handled based on needscompositedscroling which may be different because of lcd-text flag.
PaintLayerScrollableArea::ComputeNeedsCompositedScrolling() has a check for lcd-text flag.

Yes, ComputeGraphicsLayerParentLocation is a good place to look.  If the content is offset as well as the scrollbars, then the position of the main GraphicsLayer should be adjusted.

I don't think it needs to look at NeedsCompositedScrolling() - on low DPI the iframe won't even get a CompositedLayerMapping.

Probably it works without RLS because of CompositedLayerMapping::UpdateAfterPartResize.  This method looks like it's propagating iframe border/padding (from ContentsBox) into the position of PaintLayerCompositor::overflow_controls_host_layer_, which no longer exists with RLS.

The main document layer is composited, whose bounds are 0,0 796x560             (Layer 1)
Next layer composited is (IFrames document), whose bounds are 0,0 300x150       (Layer 2)
Next layer composited is LayoutIFrame IFRAME, whose bounds are 8,8 340x190      (Layer 3)

now the issue is when Layer 2 is composited , it is composited with 300x150 bounds 
(which is unware of the border of iframe) based on this overflow-controls-host-layer 
is created.

Re. #13: Note that the <iframe> element layer (Layer 3) is the parent of the iframe document layer (Layer 2).  We want the iframe document layer to have position (20,20) in this case, rather than (0,0).

Maybe CLM::UpdateAfterPartResize should apply this offset?  E.g.

  if (GetLayoutObject().IsLayoutEmbeddedContent()) {
    Document* document = ToHTMLFrameOwnerElement(
        GetLayoutObject().GetNode())->contentDocument();

    GraphicsLayer* document_layer = document->GetLayoutView()->
        Layer()->CompositedLayerMapping()->MainGraphicsLayer();

    document_layer->SetPosition(ContentsBox().Location());
  }

By applying the offset layer is placed properly. But while scrolling the #document layer of iframe again its position is replaced back to (0,0) as same calculations happen setting the offset of the layer to (0,0).

do we need to add similar apis like FrameViewDidChangeSize in CLM ?

WIP : https://chromium-review.googlesource.com/c/chromium/src/+/709134

http://crrev.com/c/717741 should fix this

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4d9b75dd5cb3c54f3b80cabed4b05c29a2133b0f

commit 4d9b75dd5cb3c54f3b80cabed4b05c29a2133b0f
Author: Steve Kobes <skobes@chromium.org>
Date: Fri Oct 13 23:56:40 2017

[RLS] Fix layer positioning with iframe borders.

The offset of the <iframe> element's ContentBoxRect is now reflected in the
position of the main GraphicsLayer of the iframe's document.

Without RLS, this position was applied to PLC::overflow_controls_host_layer_
via FrameViewDidChangeLocation.

The position is computed by both the document CLM and the <iframe> element's
CLM.  This is because the compositing update may run in the child frame before
or after the parent frame.

Bug:  746777 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I8815a1b7336330ba7798bc460c21f1acdac7c668
Reviewed-on: https://chromium-review.googlesource.com/717741
Commit-Queue: Steve Kobes <skobes@chromium.org>
Reviewed-by: Stefan Zager <szager@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508878}
[modify] https://crrev.com/4d9b75dd5cb3c54f3b80cabed4b05c29a2133b0f/third_party/WebKit/LayoutTests/FlagExpectations/root-layer-scrolls
[modify] https://crrev.com/4d9b75dd5cb3c54f3b80cabed4b05c29a2133b0f/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.cpp
[modify] https://crrev.com/4d9b75dd5cb3c54f3b80cabed4b05c29a2133b0f/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.h