Bug 1361618 - Remove unnecessary calls to FlushPendingLinkUpdates. r=dbaron
☠☠ backed out by 2fba314d7de7 ☠ ☠
authorJ. Ryan Stinnett <jryans@gmail.com>
Thu, 29 Jun 2017 11:31:52 -0700
changeset 371683 9a7b90cf8a63ac8bbee85c0b2333902dd74cc5fe
parent 371682 3b300771889a7aa79167c837d2396bd0bd9bda80
child 371684 c0e98ba118f16aee0d7101bd9a3ddb9945031b58
push id47541
push userjryans@gmail.com
push dateFri, 28 Jul 2017 18:09:20 +0000
treeherderautoland@9a7b90cf8a63 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1361618 - Remove unnecessary calls to FlushPendingLinkUpdates. r=dbaron This removes the two calls to `FlushPendingLinkUpdates` in nsCSSFrameConstructor and GeckoRestyleManager, which appear to have no effect. Looking through what the pending link code is attempting to do: * When a new anchor is bound in `BindToTree` we do: 1. Link::ResetLinkState(false, Link::ElementHasHref()); * Set link's mLinkState to default (either unvisited or not link) * Set element's link mState bits to default (either unvisited or not link) 2. doc->RegisterPendingLinkUpdate(this); * Schedules idle dispatch to run `FlushPendingLinkUpdates` within 1 sec * In `FlushPendingLinkUpdates`: * For each pending link, call element->UpdateLinkState(link->LinkState()); 1. Register link for async history update to get potential future visited state 2. mLinkState is still unvisited / not link until we hear from history, so element state is unchanged Thus, there seems to be no need to call `FlushPendingLinkUpdates` outside of `BindToTree`, since visited state is always applied async anyway (so it doesn't work as an optimization to avoid restyling if visited, since that will trigger later). MozReview-Commit-ID: KbFuKve1KUi
--- a/layout/base/GeckoRestyleManager.cpp
+++ b/layout/base/GeckoRestyleManager.cpp
@@ -1818,17 +1818,16 @@ ElementRestyler::Restyle(nsRestyleHint a
       // up the hint for one of the ancestors that we hit first, then
       // we'll fail to do the restyling we need to do.
       // Likewise, if we're restyling something with two nested frames,
       // and we post a restyle from the transition manager while
       // computing style for the outer frame (to be computed after the
       // descendants have been resolved), we don't want to consume it
       // for the inner frame.
       mContent->GetPrimaryFrame() == mFrame) {
-    mContent->OwnerDoc()->FlushPendingLinkUpdates();
     nsAutoPtr<RestyleTracker::RestyleData> restyleData;
     if (mRestyleTracker.GetRestyleData(mContent->AsElement(), restyleData)) {
       nsChangeHint changeToAppend =
       // See the comment in CaptureChange about why we use NS_IsHintSubset here.
       if (!NS_IsHintSubset(changeToAppend, mHintsHandledBySelf)) {
         mHintsHandledBySelf |= changeToAppend;
--- a/layout/base/nsCSSFrameConstructor.cpp
+++ b/layout/base/nsCSSFrameConstructor.cpp
@@ -5151,17 +5151,16 @@ nsCSSFrameConstructor::ResolveStyleConte
 nsCSSFrameConstructor::ResolveStyleContext(nsStyleContext* aParentStyleContext,
                                            nsIContent* aContent,
                                            nsFrameConstructorState* aState,
                                            Element* aOriginatingElementOrNull)
   StyleSetHandle styleSet = mPresShell->StyleSet();
-  aContent->OwnerDoc()->FlushPendingLinkUpdates();
   RefPtr<nsStyleContext> result;
   if (aContent->IsElement()) {
     auto pseudoType = aContent->AsElement()->GetPseudoElementType();
     if (pseudoType == CSSPseudoElementType::NotPseudo) {
       if (aState) {
         result = styleSet->ResolveStyleFor(aContent->AsElement(),