New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document leak on pages with text input forms such as google.com #13764
Document leak on pages with text input forms such as google.com #13764
Conversation
EWS run on previous version of this PR (hash aff8850) |
I will try to write a layout test. |
aff8850
to
36a95c9
Compare
EWS run on previous version of this PR (hash 36a95c9) |
Added a layout test. |
Should we also clear the state kept in the UIProcess? WebPageProxy::registerEditCommand adds a command proxy object for the undo steps we'll be clearing in the Web process. I didn't see the code path for clearing commands get hit in my manual tests. |
I'll check but |
With my patch, I see the WebEditCommandProxy destructor getting called in the UIProcess. |
36a95c9
to
62f95d5
Compare
EWS run on previous version of this PR (hash 62f95d5) |
62f95d5
to
be62b9c
Compare
EWS run on previous version of this PR (hash be62b9c) |
Re-requesting review as I had to make a few changes to make all tests pass. |
Classic. Reverse member order destruction. |
It is actually about construction. We need to make sure the EditorClient gets constructed before the main frame and thus its document. This is because the Document constructor will construct the "Editor" which now grabs the EditorClient from the Page. |
Ah I was looking at the crashes which looked like they asserted on the EditorClient having already been destroyed before we got to the Frame destructor. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a question.
be62b9c
to
54b53fa
Compare
EWS run on current version of this PR (hash 54b53fa) |
if (Page* page = m_document.page()) | ||
return &page->editorClient(); | ||
return nullptr; | ||
ASSERT(!m_client || !m_document.page() || m_client == &m_document.page()->editorClient()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@whsieh I added the assertion here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense β thanks!
https://bugs.webkit.org/show_bug.cgi?id=256404 rdar://108975202 Reviewed by Wenson Hsieh and Ryosuke Niwa. When typing test in a text input field and then navigating away, the text field's document would leak. It would be kept alive via a WebUndoStep stored in the WebPage::m_undoStepMap map. FrameLoader::closeURL() was calling Editor::clearUndoRedoOperations() to clear those WebUndoSteps on the WebPage. However, it ended up being a no-op because Editor::client() would return null because the document was already detached from the frame and the EditorClient is stored on the Page. This happens in particular when the previous page was put in the back/forward cache. To address the issue, I updated Editor to store a WeakPtr to the EditorClient object so that it is always able to tell the client to clear operations if the Page/EditorClient are still alive. * Source/WebCore/editing/Editor.cpp: (WebCore::Editor::client const): (WebCore::Editor::Editor): * Source/WebCore/editing/Editor.h: Canonical link: https://commits.webkit.org/264022@main
54b53fa
to
b9a32bf
Compare
Committed 264022@main (b9a32bf): https://commits.webkit.org/264022@main Reviewed commits have been landed. Closing PR #13764 and removing active labels. |
b9a32bf
54b53fa