RESOLVED FIXED 214816
SOAuthorizationSession::dismissViewController could crash on calling WebPageProxy::platformWindow
https://bugs.webkit.org/show_bug.cgi?id=214816
Summary SOAuthorizationSession::dismissViewController could crash on calling WebPageP...
Jiewen Tan
Reported 2020-07-26 23:33:23 PDT
SOAuthorizationSession::dismissViewController presentingWindow could be null.
Attachments
Patch (2.91 KB, patch)
2020-07-26 23:37 PDT, Jiewen Tan
no flags
Patch (1.90 KB, patch)
2020-07-31 01:45 PDT, Jiewen Tan
no flags
Patch (2.61 KB, patch)
2020-07-31 12:33 PDT, Jiewen Tan
youennf: review+
Patch for landing (1.50 KB, patch)
2020-07-31 12:59 PDT, Jiewen Tan
no flags
Jiewen Tan
Comment 1 2020-07-26 23:33:43 PDT
Jiewen Tan
Comment 2 2020-07-26 23:37:51 PDT
Darin Adler
Comment 3 2020-07-27 12:20:30 PDT
Comment on attachment 405261 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=405261&action=review > Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:300 > if (m_page && m_page->platformWindow()) { WebKit coding style proposes a style called early exit. Since this code already has "return" statements in it, I think it’s a good candidate for that style. > Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:301 > + if (auto *presentingWindow = m_page->platformWindow()) { Why is it valuable to check this for null again? The line of code just above this already checks it for null. This patch seems to be based on an incorrect assumption that it’s not.
Jiewen Tan
Comment 4 2020-07-27 14:04:05 PDT
Comment on attachment 405261 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=405261&action=review >> Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:300 >> if (m_page && m_page->platformWindow()) { > > WebKit coding style proposes a style called early exit. Since this code already has "return" statements in it, I think it’s a good candidate for that style. There is another if closure after, which is in parallel with this one. Just doing an early return here might not be sufficient. >> Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:301 >> + if (auto *presentingWindow = m_page->platformWindow()) { > > Why is it valuable to check this for null again? The line of code just above this already checks it for null. This patch seems to be based on an incorrect assumption that it’s not. Right, I checked that already. I will double check where could cause a null pointer dereference on m_page.
Jiewen Tan
Comment 5 2020-07-31 01:45:02 PDT
youenn fablet
Comment 6 2020-07-31 02:46:18 PDT
Comment on attachment 405676 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=405676&action=review > Source/WebKit/ChangeLog:10 > + needs to check WebPageProxy:isClosed() befored calling platformWindow(). It seems that WebPageProxy::platformWindow implementation is brittle. Shouldn't we then update WebPageProxy::platformWindow so that it checks that m_pageClient is not null and, if null, return nil? Is it possible to write a test?
Jiewen Tan
Comment 7 2020-07-31 12:06:36 PDT
(In reply to youenn fablet from comment #6) > Comment on attachment 405676 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=405676&action=review > > > Source/WebKit/ChangeLog:10 > > + needs to check WebPageProxy:isClosed() befored calling platformWindow(). > > It seems that WebPageProxy::platformWindow implementation is brittle. > Shouldn't we then update WebPageProxy::platformWindow so that it checks that > m_pageClient is not null and, if null, return nil? > Is it possible to write a test? Unfortunately, it's not trivial to do the null check on platformWindow(). NSWindow *WebPageProxy::platformWindow() { return pageClient().platformWindow(); } pageClient() returns a reference. And for pageClient(): PageClient& WebPageProxy::pageClient() const { ASSERT(m_pageClient); return *m_pageClient; } It seems to me a too large a change to make pageClient() return a pointer instead of a reference for fixing this crash and might very well be too large to land for the upcoming release. I remember last time when I tried to write such a test, I failed. See Bug 199755. So, it's not trivial to write a test.
Darin Adler
Comment 8 2020-07-31 12:09:43 PDT
(In reply to Jiewen Tan from comment #7) > Unfortunately, it's not trivial to do the null check on platformWindow(). > NSWindow *WebPageProxy::platformWindow() > { > return pageClient().platformWindow(); > } return m_pageClient ? m_pageClient->platformWindow() : nullptr;
Jiewen Tan
Comment 9 2020-07-31 12:31:25 PDT
(In reply to Darin Adler from comment #8) > (In reply to Jiewen Tan from comment #7) > > Unfortunately, it's not trivial to do the null check on platformWindow(). > > NSWindow *WebPageProxy::platformWindow() > > { > > return pageClient().platformWindow(); > > } > > return m_pageClient ? m_pageClient->platformWindow() : nullptr; Done.
Jiewen Tan
Comment 10 2020-07-31 12:33:27 PDT
youenn fablet
Comment 11 2020-07-31 12:47:40 PDT
Comment on attachment 405721 [details] Patch Can we remove the isClosed check?
Jiewen Tan
Comment 12 2020-07-31 12:50:02 PDT
(In reply to youenn fablet from comment #11) > Comment on attachment 405721 [details] > Patch > > Can we remove the isClosed check? Sure.
Jiewen Tan
Comment 13 2020-07-31 12:59:00 PDT
Created attachment 405726 [details] Patch for landing
Jiewen Tan
Comment 14 2020-07-31 12:59:27 PDT
Thanks Youenn and Darin for reviewing this patch!
EWS
Comment 15 2020-07-31 13:39:09 PDT
Committed r265158: <https://trac.webkit.org/changeset/265158> All reviewed patches have been landed. Closing bug and clearing flags on attachment 405726 [details].
Note You need to log in before you can comment on or make changes to this bug.