Bug 1368852: Avoid flushing frames from nsHideViewer if we know we're not going to get a frame. r?dholbert draft
authorEmilio Cobos Álvarez <emilio@crisal.io>
Wed, 13 Sep 2017 00:08:46 +0200
changeset 663340 67e6d75dc9ef178bb7a9f71bbad3b2c4ae502ee4
parent 663134 a73cc4e08bf5a005722c95b43f84ab0c8ff2bc7c
child 731183 a6bb742e693b1f7da3f489aa12ce03179f147134
push id79414
push userbmo:emilio@crisal.io
push dateTue, 12 Sep 2017 22:29:12 +0000
reviewersdholbert
bugs1368852
milestone57.0a1
Bug 1368852: Avoid flushing frames from nsHideViewer if we know we're not going to get a frame. r?dholbert MozReview-Commit-ID: ATVMfQ8myC1
layout/generic/nsSubDocumentFrame.cpp
--- a/layout/generic/nsSubDocumentFrame.cpp
+++ b/layout/generic/nsSubDocumentFrame.cpp
@@ -925,17 +925,26 @@ public:
     NS_ASSERTION(mPresShell, "Must have a presshell");
   }
 
   NS_IMETHOD Run() override
   {
     // Flush frames, to ensure any pending display:none changes are made.
     // Note it can be unsafe to flush if we've destroyed the presentation
     // for some other reason, like if we're shutting down.
-    if (!mPresShell->IsDestroying()) {
+    //
+    // But avoid the flush if we know for sure we're away, like when we're out
+    // of the document already.
+    //
+    // FIXME(emilio): This could still be a perf footgun when removing lots of
+    // siblings where each of them cause the reframe of an ancestor which happen
+    // to contain a subdocument.
+    //
+    // We should find some way to avoid that!
+    if (!mPresShell->IsDestroying() && mFrameElement->IsInComposedDoc()) {
       mPresShell->FlushPendingNotifications(FlushType::Frames);
     }
 
     // Either the frame has been constructed by now, or it never will be,
     // either way we want to clear the stashed views.
     mFrameLoader->SetDetachedSubdocFrame(nullptr, nullptr);
 
     nsSubDocumentFrame* frame = do_QueryFrame(mFrameElement->GetPrimaryFrame());