Bug 74059 - WebKit consumes a lot of memory in unused undo stack on GMail
Summary: WebKit consumes a lot of memory in unused undo stack on GMail
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 79001 64414 74099
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-07 23:29 PST by Ryosuke Niwa
Modified: 2017-07-18 08:30 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2011-12-07 23:29:45 PST
It appears that we only clear undo stack when the main frame is unloaded (at least on Chromium) but the user never navigates on GMail so this becomes an issue. We end up accumulating tons of EditingText, spans, divs, etc... we created along the way in the undo stack even though GMail's editor never use them (they have their own undo stack).

We should at least clear EditCommands that belong to unloaded frames.
Comment 1 Ojan Vafai 2011-12-08 10:26:14 PST
In an ideal world we would remove all entries in the undo stack of editing roots that are garbage collected.
Comment 2 Ryosuke Niwa 2011-12-08 10:50:51 PST
(In reply to comment #1)
> In an ideal world we would remove all entries in the undo stack of editing roots that are garbage collected.

Right. But it's quite tricky because a node can be transition between editable root and non-editable root. Also, you can insert/remove a editable root from/to a document in undo/redo such that subsequent undo/redo depends on this root.  So being garbage collected isn't a sufficient condition for us to automatically remove entries.

Even removing all undo entries that belong to one frame is tricky in the world where we have implemented UndoManager & DOM Transaction spec because a node can move from one frame to another. Just because source or destination frame got removed doesn't mean we can remove all entries corresponding to those frames. In fact, one command can interact with arbitrary number of frames in theory.