Track reasons for |Node::SetNeedsStyleRecalc|

Source/core/dom/StyleChangeReason.h

Index: Source/core/dom/StyleChangeReason.h
diff --git a/Source/core/dom/StyleChangeReason.h b/Source/core/dom/StyleChangeReason.h
new file mode 100644
index 0000000000000000000000000000000000000000..83f8ea53b311adcf4e2de165a431f3b758cf109c
--- /dev/null
+++ b/Source/core/dom/StyleChangeReason.h
@@ -0,0 +1,84 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef StyleChangeReason_h
+#define StyleChangeReason_h
+
+#include "wtf/Assertions.h"
+
+namespace blink {
+
+enum StyleChangeReason {

[pdr., 2014/09/06 22:36:28]

Please add a comment here about what this is for, noting that we should not use
this for comparisons.

[kouhei (in TOK), 2014/09/06 23:10:34]

Ack. I think we should rename the type too so that its obvious.
StyleChangeReasonForTracing(Only)?

[kouhei (in TOK), 2014/09/08 23:29:12]

Done.

+    StyleRecalcDueToActivePseudoClass,

[pdr., 2014/09/06 22:36:28]

Ultimately we will need to send this data via a trace event. A simple way to do
this is to use strings and provide a helper static on StyleChangeReason for
getting the string representation.

Another way to do this is to just use integers and keep a ReasonInt->String list
up to date in devtools. If we go this route, we will need to use numbers here,
similar to UseCounter.h's Feature enum which prevents people from adding new
values in the middle.

[kouhei (in TOK), 2014/09/06 23:10:34]

Integers route seems better to me, as it would likely have less overhead and we
would not need to violate the no comparison rule.

[kouhei (in TOK), 2014/09/08 23:29:12]

Done.

+    StyleRecalcDueToActiveStylesheetsUpdate,
+    StyleRecalcDueToAnimation,
+    StyleRecalcDueToAttribute,
+    StyleRecalcDueToAuthorStyles,
+    StyleRecalcDueToCellBorderPaddingChange,
+    StyleRecalcDueToChildren,
+    StyleRecalcDueToControl,
+    StyleRecalcDueToControlValue,
+    StyleRecalcDueToCustomElement,
+    StyleRecalcDueToDesignMode,
+    StyleRecalcDueToDetach,
+    StyleRecalcDueToDirectionality,
+    StyleRecalcDueToDisabledPseudoClass,
+    StyleRecalcDueToDrag,
+    StyleRecalcDueToEmptyPseudoClass,
+    StyleRecalcDueToExitingCompositingMode,
+    StyleRecalcDueToFocusPseudoClass,
+    StyleRecalcDueToFontSizeChange,
+    StyleRecalcDueToFonts,
+    StyleRecalcDueToFrameSet,
+    StyleRecalcDueToFullScreen,
+    StyleRecalcDueToHoverPseudoClass,
+    StyleRecalcDueToImageAltText,
+    StyleRecalcDueToInline,
+    StyleRecalcDueToInsertionPoint,
+    StyleRecalcDueToInspector,
+    StyleRecalcDueToInvalidPseudoClass,
+    StyleRecalcDueToLanguage,
+    StyleRecalcDueToLayerUpdate,
+    StyleRecalcDueToLinkColorChange,
+    StyleRecalcDueToPlatformColorChange,
+    StyleRecalcDueToPlugin,
+    StyleRecalcDueToRequiredOptionalPseudoClass,
+    StyleRecalcDueToResolver,
+    StyleRecalcDueToSVGContainerSizeChange,
+    StyleRecalcDueToSVGCursor,
+    StyleRecalcDueToSVGFilterLayerUpdateHack,
+    StyleRecalcDueToSVGUseElement,
+    StyleRecalcDueToSeamlessIFrame,
+    StyleRecalcDueToSelector,
+    StyleRecalcDueToShadow,
+    StyleRecalcDueToSiblingSelector,
+    StyleRecalcDueToStyleInheritanceChange,
+    StyleRecalcDueToStyleSheetChange,
+    StyleRecalcDueToTreeScope,
+    StyleRecalcDueToValidity,
+    StyleRecalcDueToViewportUnits,
+    StyleRecalcDueToVisitedLink,
+    StyleRecalcDueToVisuallyOrdered,
+    StyleRecalcDueToWritingModeChange,
+    StyleRecalcDueToZoom,

[rune, 2014/09/08 08:27:57]

These constants are very tied up to implementation details. Are they supposed to
be useful for authors? The fact that they're tied up to implementation details.
It means the use of these constants are subject to change, and the need for many
of them will hopefully not be there in the near future. More and more of this
should be moved to happen inside the StyleInvalidator which means
StyleRecalcDueToSelector with the current code?

I think they can be quite useful for blink developers, but I'm not so sure about
authors.

There already exists inspector functionality for finding the source of e.g.
style invalidation due to class changes which gives you a javascript call stack
of the site of setting className that is more informative than getting a
StyleRecalcDueToSelector. I don't know that code, so I don't know if it's
special for class.

[kouhei (in TOK), 2014/09/08 23:29:12]

These are internal reasons, but we still want to have these information
available to page authors for inspecting.
This is not exposed as WebAPI but only visible via devtools/about:tracing, so we
want to show as much as we can, just like we show compositing layer info in
devtools.

Yes, StyleRecalcs from StyleInvalidator should have more info.
I'm planning to also add trace event to setNeedsStyleInvalidation from
RuleFeatureSet::scheduleStyleInvalidationForX, then connect those events from
post-processing in devtools.
I didn't know about the feature. Would you tell me how I can try it?

+};
+
+#define DISALLOW_COMPARISON_OPERATOR(TYPE, OP) \
+    inline bool OP(TYPE, TYPE)                 \
+    {                                          \
+        ASSERT_NOT_REACHED();                  \
+        return true;                           \
+    }
+#define DISALLOW_ALL_COMPARISON_OPERATORS(TYPE)    \

[pdr., 2014/09/06 22:36:27]

Clever!

+    DISALLOW_COMPARISON_OPERATOR(TYPE, operator>)  \
+    DISALLOW_COMPARISON_OPERATOR(TYPE, operator<)  \
+    DISALLOW_COMPARISON_OPERATOR(TYPE, operator<=) \
+    DISALLOW_COMPARISON_OPERATOR(TYPE, operator>=) \
+    DISALLOW_COMPARISON_OPERATOR(TYPE, operator==) \
+    DISALLOW_COMPARISON_OPERATOR(TYPE, operator!=)
+DISALLOW_ALL_COMPARISON_OPERATORS(StyleChangeReason)

[pdr., 2014/09/06 22:36:27]

We may end up needing to make these operators private so we can use them in this
file.

+
+} // namespace blink
+
+#endif // StyleChangeReason_h