Intersection Observer first draft

Source/core/frame/FrameView.cpp

Index: Source/core/frame/FrameView.cpp
diff --git a/Source/core/frame/FrameView.cpp b/Source/core/frame/FrameView.cpp
index e4635d9f6241e3ebe2688d4f991e65c383eaba5e..b8b87101b64bf991b67319a1162f95b01e849685 100644
--- a/Source/core/frame/FrameView.cpp
+++ b/Source/core/frame/FrameView.cpp
@@ -34,6 +34,7 @@
 #include "core/css/resolver/StyleResolver.h"
 #include "core/dom/AXObjectCache.h"
 #include "core/dom/Fullscreen.h"
+#include "core/dom/IntersectionObserver.h"
 #include "core/editing/EditingUtilities.h"
 #include "core/editing/FrameSelection.h"
 #include "core/editing/RenderedPosition.h"
@@ -1116,6 +1117,46 @@ void FrameView::invalidateTreeIfNeeded(PaintInvalidationState& paintInvalidation
 
     m_doFullPaintInvalidation = false;
     lifecycle().advanceTo(DocumentLifecycle::PaintInvalidationClean);
+
+    if (RuntimeEnabledFeatures::intersectionObserverEnabled()) {
+        computeIntersectionObservations(paintInvalidationState);
+    }
+}
+
+void FrameView::computeIntersectionObservations(PaintInvalidationState& paintInvalidationState)
+{
+    ASSERT(layoutView());
+    LayoutView& rootForPaintInvalidation = *layoutView();
+
+    if (FrameView* parent = parentFrameView()) {

[liberato (no reviews please), 2015/09/04 15:07:46]

how will you handle different containing views ("viewport:" in the doc)?

if every PositionObserver can specify its own element as its viewport, then
FrameView might not be the right place for this.  perhaps just notify LayoutView
what the default viewport bounds are currently, and let it iterate over position
observers.

also, relatedly, do we really need viewportModifierLength at all?  one can just
stick the content in a larger div, itself inside an overflow:hidden div, then
set up an observer using the inner, larger one.

i realize i'm making a few assumptions in there about interpretation of
"visible".  seems like a useful thing.

[MikeB, 2015/09/04 17:59:33]

I think viewportModifierLength is being dropped. I'm not entirely convinced we
need the 'viewport' option either. 

+        m_clippedBounds = IntRect(frameRect().location(), paintInvalidationState.clipRect().pixelSnappedSize());
+        m_clippedBounds = parent->contentsToRootFrame(m_clippedBounds);
+        m_clippedBounds.intersect(parent->contentsToRootFrame(parent->m_clippedBounds));
+        if (!m_clippedBounds.isEmpty()) {
+            m_clippedBounds = rootFrameToContents(m_clippedBounds);
+        }
+    } else {
+        m_clippedBounds = pixelSnappedIntRect(paintInvalidationState.clipRect());

[liberato (no reviews please), 2015/09/04 15:07:46]

is this correct if one zooms?  i believe so.

[MikeB, 2015/09/04 17:59:34]

Good question. I can test!

+    }
+
+    FloatRect viewport(m_clippedBounds);
+    for (auto& obj : rootForPaintInvalidation.intersectionObserverTargets()) {

[liberato (no reviews please), 2015/09/04 15:07:46]

independently of the above comment about moving this entire fn into LayoutView,
this loop might still go better in LayoutView --
LayoutView::someVerbIntersectionObservers(viewport).  the loop just accesses
LayoutView state indirectly anyway.

[MikeB, 2015/09/04 17:59:33]

Fair point.

+        Node* node = obj.key->node();

[liberato (no reviews please), 2015/09/04 15:07:46]

for clarity, "LayoutObject* layoutObect = obj.key"

+        if (!node || !node->isElementNode())
+            continue;
+        FloatRect bounds = obj.key->absoluteBoundingBoxFloatRect();
+        bounds.intersect(viewport);
+        const FloatRect& oldBounds = obj.value;
+        if (oldBounds == bounds)
+            continue;
+        obj.value = bounds;
+        Element* element = toElement(node);
+        Vector<FloatRect> quads;
+        quads.append(bounds);

[liberato (no reviews please), 2015/09/04 15:07:46]

this brings up a question i had about the doc.  i'm a little unclear about the
vector of quads per observation.  are you picturing eventually checking for 
"element is in viewport but partially occluded by this other element", so that
it has a non-rectangular visible region?  or are there other ways to get
non-rectangular intersections that i'm missing?

personally, i don't quite see the value in that.  given notification that
something has moved / scrolled / etc., JS can fairly easily do additional
intersection tests as it likes.  the key value that i see is detecting those
changes in an efficient way with respect to some enclosing element or default
viewport, and including the "thresholdCallbacks" debounce logic.

same for questions about alpha / opacity raised in the doc.  seems really tricky
and hard to get behavior that makes everybody happy.

[MikeB, 2015/09/04 17:59:33]

According to the guys who drafted that particular piece, it was intended to
account for skew transforms and things like that. I'm actually passing a vector
of a single rect every time right now. We'll iterate with the spec a bit.

+        for (auto& observer : element->intersectionObservers()) {
+            observer->enqueueIntersectionObserverEntry(IntersectionObserverEntry::create(0, quads, viewport, element));
+        }
+    }
 }
 
 DocumentLifecycle& FrameView::lifecycle() const