Bug 1061469 - part 5: Fixing up update for Imports. r=mrbkap
☠☠ backed out by 4116e175b2e0 ☠ ☠
authorGabor Krizsanits <gkrizsanits@mozilla.com>
Thu, 02 Oct 2014 09:54:09 +0200
changeset 231580 01ead7a7bb5ddf9a91b9debacd153bd5449fdfc5
parent 231579 1008e478d1002f12c40cd4d832eabfc00ecf154e
child 231581 62486f51f316a525ed6506fe2e3a1565db1016e0
push id4187
push userbhearsum@mozilla.com
push dateFri, 28 Nov 2014 15:29:12 +0000
treeherdermozilla-beta@f23cc6a30c11 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersmrbkap
bugs1061469
milestone35.0a1
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 1061469 - part 5: Fixing up update for Imports. r=mrbkap
content/base/src/ImportManager.cpp
--- a/content/base/src/ImportManager.cpp
+++ b/content/base/src/ImportManager.cpp
@@ -86,16 +86,20 @@ ImportLoader::Updater::GetReferrerChain(
   for (uint32_t i = 0; i < l / 2; i++) {
     Swap(aResult[i], aResult[l - i - 1]);
   }
 }
 
 bool
 ImportLoader::Updater::ShouldUpdate(nsTArray<nsINode*>& aNewPath)
 {
+  if (mLoader->Manager()->GetNearestPredecessor(mLoader->GetMainReferrer()) !=
+      mLoader->mBlockingPredecessor) {
+    return true;
+  }
   // Let's walk down on the main referrer chains of both the current main and
   // the new link, and find the last pair of links that are from the same
   // document. This is the junction point between the two referrer chain. Their
   // order in the subimport list of that document will determine if we have to
   // update the spanning tree or this new edge changes nothing in the script
   // execution order.
   nsTArray<nsINode*> oldPath;
   GetReferrerChain(mLoader->mLinks[mLoader->mMainReferrer], oldPath);