RESOLVED FIXED 232047
Launch Services database is not always sent to GPUP
https://bugs.webkit.org/show_bug.cgi?id=232047
Summary Launch Services database is not always sent to GPUP
Per Arne Vollan
Reported 2021-10-20 14:24:28 PDT
Currently, the XPC endpoint for receiving the Launch Services database is being sent to GPUP in GPUProcessProxy::addSession. If GPUP has not finished launching at that point, the endpoint will not be sent.
Attachments
Patch (4.64 KB, patch)
2021-10-20 14:28 PDT, Per Arne Vollan
no flags
Patch (4.70 KB, patch)
2021-10-20 15:03 PDT, Per Arne Vollan
no flags
Patch (4.89 KB, patch)
2021-10-20 15:09 PDT, Per Arne Vollan
bfulgham: review+
Patch (4.88 KB, patch)
2021-10-20 15:12 PDT, Per Arne Vollan
no flags
Patch (3.04 KB, patch)
2021-10-21 08:56 PDT, Per Arne Vollan
no flags
Patch (3.04 KB, patch)
2021-10-21 08:59 PDT, Per Arne Vollan
no flags
Per Arne Vollan
Comment 1 2021-10-20 14:28:36 PDT
Radar WebKit Bug Importer
Comment 2 2021-10-20 14:50:24 PDT
Per Arne Vollan
Comment 3 2021-10-20 15:03:42 PDT
Brent Fulgham
Comment 4 2021-10-20 15:05:38 PDT
Comment on attachment 441943 [details] Patch r=me
Per Arne Vollan
Comment 5 2021-10-20 15:09:01 PDT
Per Arne Vollan
Comment 6 2021-10-20 15:12:41 PDT
Per Arne Vollan
Comment 7 2021-10-20 15:14:37 PDT
Comment on attachment 441945 [details] Patch Thanks for reviewing!
Darin Adler
Comment 8 2021-10-20 15:31:51 PDT
Comment on attachment 441938 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=441938&action=review Some additional thoughts. > Source/WebKit/UIProcess/GPU/GPUProcessProxy.cpp:439 > + auto it = m_sessionIDs.begin(); > + if (it != m_sessionIDs.end()) { > + auto webSiteDataStore = WebsiteDataStore::existingDataStoreForSessionID(*m_sessionIDs.begin()); This is a slightly unusual pattern. Since m_sessionIDs is a HashSet, choosing the first by iterating gives you an arbitrary member of the set, variable. If that is indeed what you want then I suppose this is OK, but note that this is neither truly random, nor fits any reliable pattern. Almost worth a comment explaining why it’s OK to use only one of the session IDs in a set, because I do not think that is obvious. Maybe just a comment saying "all session IDs are guaranteed to have the same data store". Coding style wise, this calls begin() an extra time even though it uses a local variable. There are two ways I might write this that I think would be good style: // <Comment explaining why choosing an arbitrary session ID is OK, but random is not needed.> if (auto it = m_sessionIDs.begin(); it != m_sessionIDs.end()) { auto store = WebsiteDataStore::existingDataStoreForSessionID(*it); Or: // <Comment explaining why choosing an arbitrary session ID is OK, but random is not needed.> if (!m_sessionIDs.isEmpty()) { auto store = WebsiteDataStore::existingDataStoreForSessionID(m_sessionIDs.begin()); Also, how solid is the guarantee that existingDataStoreForSessionID will not return null?
Per Arne Vollan
Comment 9 2021-10-20 15:59:42 PDT
(In reply to Darin Adler from comment #8) > Comment on attachment 441938 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=441938&action=review > > Some additional thoughts. > > > Source/WebKit/UIProcess/GPU/GPUProcessProxy.cpp:439 > > + auto it = m_sessionIDs.begin(); > > + if (it != m_sessionIDs.end()) { > > + auto webSiteDataStore = WebsiteDataStore::existingDataStoreForSessionID(*m_sessionIDs.begin()); > > This is a slightly unusual pattern. Since m_sessionIDs is a HashSet, > choosing the first by iterating gives you an arbitrary member of the set, > variable. If that is indeed what you want then I suppose this is OK, but > note that this is neither truly random, nor fits any reliable pattern. > Almost worth a comment explaining why it’s OK to use only one of the session > IDs in a set, because I do not think that is obvious. Maybe just a comment > saying "all session IDs are guaranteed to have the same data store". > > Coding style wise, this calls begin() an extra time even though it uses a > local variable. There are two ways I might write this that I think would be > good style: > > // <Comment explaining why choosing an arbitrary session ID is OK, but > random is not needed.> > if (auto it = m_sessionIDs.begin(); it != m_sessionIDs.end()) { > auto store = WebsiteDataStore::existingDataStoreForSessionID(*it); > > Or: > > // <Comment explaining why choosing an arbitrary session ID is OK, but > random is not needed.> > if (!m_sessionIDs.isEmpty()) { > auto store = > WebsiteDataStore::existingDataStoreForSessionID(m_sessionIDs.begin()); > That is a good point. I will upload a revised patch, adopting one of these approaches and adding a comment. The reason any session ID is OK to use, is that we're looking to get the XPC endpoint from any Networking process. All Networking processes has this endpoint, and it does not matter from which Networking process we get it from. > Also, how solid is the guarantee that existingDataStoreForSessionID will not > return null? That is also a good point. Although unlikely, I think it is possible that the data store for this session has been removed at this point, since this session ID is kept in a hash map not controlled by the data store class. I will add a null check here. Thanks for reviewing!
EWS
Comment 10 2021-10-20 16:07:21 PDT
Committed r284582 (243319@main): <https://commits.webkit.org/243319@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 441945 [details].
Per Arne Vollan
Comment 11 2021-10-21 08:56:02 PDT
Reopening to attach new patch.
Per Arne Vollan
Comment 12 2021-10-21 08:56:03 PDT
Per Arne Vollan
Comment 13 2021-10-21 08:59:56 PDT
Per Arne Vollan
Comment 14 2021-10-21 13:15:41 PDT
I believe the api-gtk are unrelated to the patch.
EWS
Comment 15 2021-10-21 13:36:16 PDT
Committed r284641 (243361@main): <https://commits.webkit.org/243361@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 442033 [details].
Note You need to log in before you can comment on or make changes to this bug.