Open Bug 853042 Opened 12 years ago Updated 2 years ago

Layout flushes happen for each tab during restoreHistory

Categories

(Firefox :: Session Restore, defect)

defect

Tracking

()

People

(Reporter: glandium, Unassigned)

Details

See http://people.mozilla.com/~bgirard/cleopatra/#report=7018a09860a35506fbd8d78a39d8f63284955d84 (search for layout::flush) This is triggered by the browser.stop() call in restoreHistoryPrecursor, and that ends up in nsDocShell::Stop(), nsDocLoader::Stop(), (...) and eventually PresShell::FlushPendingNotifications(). That takes 6s in that profile.
Looks like this problem still potentially exists in ContentRestore.jsm's restoreHistory. Now that we have bug 878747, is that .stop() call necessary anymore?
Flags: firefox-backlog+
Summary: Layout flushes happen for each tab during restoreHistoryPrecursor → Layout flushes happen for each tab during restoreHistory
Is there a way to batch these stops into a single non-trivial layout flush, btw?
We can easily imagine something along the lines of https://github.com/wilsonpage/fastdom to batch together expensive flushes.
It is not clear to me why we want to flush the layout in this case. We Cancel loadgroup.
(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #2) > Now that we have bug 878747, is that .stop() call necessary anymore? addTab() doesn't load and stop about:blank anymore if you pass anything else than about:blank as the URL. In the case of sessionstore we're passing about:blank and thus skip this optimization. This means there probably still is a load to cancel here.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.