Bug 1305004 - fix ReResolveStyleContext related comments. r=heycam

Fix comment only, NPOTB, DONTBUILD.

MozReview-Commit-ID: APxOg5yVw7A

--HG--
extra : rebase_source : a48180811fedda97eaf374a7777374f8c3616ce3

layout/base/RestyleTracker.h

@@ -328,7 +328,7 @@ RestyleTracker::AddPendingRestyle(Element* aElement,
 
   // We can only treat this element as a restyle root if we would
   // actually restyle its descendants (so either call
-  // ReResolveStyleContext on it or just reframe it).
+  // ElementRestyler::Restyle on it or just reframe it).
   if ((aRestyleHint & ~eRestyle_LaterSiblings) ||
       (aMinChangeHint & nsChangeHint_ReconstructFrame)) {
     Element* cur =

layout/style/nsStyleContext.h

@@ -32,7 +32,7 @@ enum class CSSPseudoElementType : uint8_t;
  * (with a few exceptions, like system color changes), the data in an
  * nsStyleContext are also immutable (with the additional exception of
  * GetUniqueStyleData).  When style data change,
- * nsFrameManager::ReResolveStyleContext creates a new style context.
+ * ElementRestyler::Restyle creates a new style context.
  *
  * Style contexts are reference counted.  References are generally held
  * by:

layout/style/nsStyleStruct.cpp

@@ -3565,17 +3565,17 @@ nsStyleContent::nsStyleContent(const nsStyleContent& aSource)
 nsChangeHint
 nsStyleContent::CalcDifference(const nsStyleContent& aNewData) const
 {
-  // In ReResolveStyleContext we assume that if there's no existing
+  // In ElementRestyler::Restyle we assume that if there's no existing
   // ::before or ::after and we don't have to restyle children of the
   // node then we can't end up with a ::before or ::after due to the
   // restyle of the node itself.  That's not quite true, but the only
   // exception to the above is when the 'content' property of the node
   // changes and the pseudo-element inherits the changed value.  Since
   // the code here triggers a frame change on the node in that case,
-  // the optimization in ReResolveStyleContext is ok.  But if we ever
+  // the optimization in ElementRestyler::Restyle is ok.  But if we ever
   // change this code to not reconstruct frames on changes to the
   // 'content' property, then we will need to revisit the optimization
-  // in ReResolveStyleContext.
+  // in ElementRestyler::Restyle.
 
   // Unfortunately we need to reframe even if the content lengths are the same;
   // a simple reflow will not pick up different text or different image URLs,

layout/style/nsTransitionManager.h

@@ -337,7 +337,7 @@ public:
   /**
    * StyleContextChanged
    *
-   * To be called from nsFrameManager::ReResolveStyleContext when the
+   * To be called from RestyleManager::TryStartingTransition when the
    * style of an element has changed, to initiate transitions from
    * that style change.  For style contexts with :before and :after
    * pseudos, aElement is expected to be the generated before/after