Main-thread scroll if we have fixed-pos children and overflow:hidden.

Source/core/page/scrolling/ScrollingCoordinator.cpp

 /*
  * Copyright (C) 2011 Apple Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 928 matching lines @@
         reasons |= ThreadedScrollingDisabled;
 
     if (!m_page->mainFrame()->isLocalFrame())
         return reasons;
     FrameView* frameView = m_page->deprecatedLocalMainFrame()->view();
     if (!frameView)
         return reasons;
 
     if (frameView->hasSlowRepaintObjects())
         reasons |= HasSlowRepaintObjects;
-    if (frameView->isScrollable() && hasVisibleSlowRepaintViewportConstrainedObjects(frameView))
+    FrameView::ScrollingReasons scrollingReasons = frameView->scrollingReasons();
+    const bool mayBeScrolledByInput = (scrollingReasons == FrameView::Scrollable);
+    const bool mayBeScrolledByScript = (scrollingReasons ==

[skobes, 2014/11/05 21:05:22]

Anything scrollable by input is also scrollable by script, so this might be
clearer as:

const bool mayBeScrolledByScript = mayBeScrolledByInput || (scrollingReasons ==
    FrameView::NotScrollableExplicitlyDisabled);

Then you can use mayBeScrolledByScript in place of canScroll in the check below.

[awoloszyn, 2014/11/05 21:33:43]

Done.

+        FrameView::NotScrollableExplicitlyDisabled);
+    const bool canScroll = mayBeScrolledByInput || mayBeScrolledByScript;
+    // TODO(awoloszyn) Currently crbug.com/304810 will let certain
+    // overflow:hidden elements scroll on the fast path, so we should not let

[skobes, 2014/11/05 21:05:22]

Nit: I think this comment should say "...scroll on the compositor thread...". 
Doesn't fast path vs. slow path refer to whether we repaint?  So a main-thread
scroll can still be "fast path" if the layer is composited.

[awoloszyn, 2014/11/05 21:33:43]

Done.

+    // this move to the fast-path as an optimization, when we have slow-repaint
+    // elements.
+    if (canScroll && hasVisibleSlowRepaintViewportConstrainedObjects(frameView)) {
         reasons |= HasNonLayerViewportConstrainedObjects;
+    }
 
     return reasons;
 }
 
 String ScrollingCoordinator::mainThreadScrollingReasonsAsText(MainThreadScrollingReasons reasons)
 {
     StringBuilder stringBuilder;
 
     if (reasons & ScrollingCoordinator::HasSlowRepaintObjects)
         stringBuilder.appendLiteral("Has slow repaint objects, ");
@@ skipping 21 matching lines @@
     bool frameIsScrollable = frameView && frameView->isScrollable();
     if (frameIsScrollable != m_wasFrameScrollable)
         return true;
 
     if (WebLayer* scrollLayer = frameView ? toWebLayer(frameView->layerForScrolling()) : nullptr)
         return blink::WebSize(frameView->contentsSize()) != scrollLayer->bounds();
     return false;
 }
 
 } // namespace blink