|Summary:||WebKit consumes a lot of memory in unused undo stack on GMail|
|Product:||WebKit||Reporter:||Ryosuke Niwa <rniwa>|
|Component:||HTML Editing||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||ap, darin, enrica, gregsimon, pfeldman|
|Version:||528+ (Nightly build)|
|Bug Depends on:||79001, 64414, 74099|
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.