Clean compositing inputs for location APIs for sticky-affected elements.

third_party/WebKit/Source/core/dom/Document.h

Index: third_party/WebKit/Source/core/dom/Document.h
diff --git a/third_party/WebKit/Source/core/dom/Document.h b/third_party/WebKit/Source/core/dom/Document.h
index 04d7cdcdbc9c1b6652df120a152158b1a2b5b80d..5434af0912e544366591c1a3ce8c2d2f856d51d2 100644
--- a/third_party/WebKit/Source/core/dom/Document.h
+++ b/third_party/WebKit/Source/core/dom/Document.h
@@ -514,6 +514,16 @@ class CORE_EXPORT Document : public ContainerNode,
   PassRefPtr<ComputedStyle> StyleForElementIgnoringPendingStylesheets(Element*);
   PassRefPtr<ComputedStyle> StyleForPage(int page_index);
 
+  // Ensures that location-based data will be valid for a given node.
+  //
+  // This will involve running style and layout if they are currently dirty, and
+  // it may also run compositing inputs as well if the node is in a sticky
+  // subtree (as the sticky offset may change the node's position).
+  //
+  // Due to this you should only call this if you definitely need valid location
+  // data, otherwise use one of the |UpdateStyleAndLayout...| methods above.
+  void EnsureAuxiliaryLocationDataValidForNode(const Node*);

[flackr, 2017/05/04 19:00:51]

Maybe we should call this EnsurePaintLocationDataValidForNode? Since sticky is a
paint effect, and the only one which affects location it is the only affect
requiring cleaning of paint related inputs.

I also have a preference for keeping the naming consistent. I.e.
EnsurePaintLocationDataValidForNode and calling the bit
location_requires_paint_clean (or something to that effect) or
EnsureStickyLocationDataValidForNode and location_requires_sticky_data.

[smcgruer, 2017/05/08 14:32:06]

Done.

+
   // Returns true if page box (margin boxes and page borders) is visible.
   bool IsPageBoxVisible(int page_index);