-
Notifications
You must be signed in to change notification settings - Fork 16.2k
browser: Create separate request context for geolocation service. #8923
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
Conversation
👍 |
1e5515f
to
4f7721e
Compare
@deepak1556 I saw a crash on the CI machine, seems to be caused by electron-archive/brightray#278:
|
* Geolocation service cannot hold reference to browser context, since it is destroyed at the end of everything and this will confuse the shutdown path of browser context. * Geolocation service run on its own thread.
cc9de3c
to
1f261ca
Compare
64a01bb
to
72adbf7
Compare
@zcbenz have fixed the crash, thanks! Depends on electron-archive/brightray#283 |
@@ -919,10 +923,6 @@ bool WebContents::OnMessageReceived(const IPC::Message& message) { | |||
// be destroyed on close, and WebContentsDestroyed would be called for it, so | |||
// we need to make sure the api::WebContents is also deleted. | |||
void WebContents::WebContentsDestroyed() { | |||
// This event is only for internal use, which is emitted when WebContents is | |||
// being destroyed. | |||
Emit("will-destroy"); |
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.
This changes the meaning of will-destroy
, for webview it is emitted before destroying WebContents
, however for normal window now it is emitted after WebContents
gets destroyed. While this works, it makes the closing logic more difficult to understand.
How about solving the crash with a fix like electron-archive/brightray#284?
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.
however for normal window now it is emitted after WebContents gets destroyed.
I just tested for normal window close and saw the event emitted before WebContentsDestroyed
is called. The change here is that either scenario 1 or 3 of webContents destruction it will always invoke will-destroy
before anything else and follow that InspectebWebContentsImpl
gets to do the cleanup first. Is there something else that I missed ?
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.
Yeah you are right, I missed how WebContents is destroyed when window is closed.
// This event is only for internal use, which is emitted when WebContents is | ||
// being destroyed. | ||
Emit("will-destroy"); | ||
CommonWebContentsDelegate::DestroyWebContents(); |
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.
CommonWebContentsDelegate::DestroyWebContents
should be made a protected
method and renamed to something else like ResetWebContents
, having a non-virtual method with the same name is not good practice.
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.
Fixed, thanks!
👍 |
This fixes a crash which happens when navigating from a webpage that uses geolocation service and then quitting the app. Test this after applying electron-archive/brightray#278
To reproduce:
youtube.com
google.com
The reason for the crash is that geolocation service is managed by a global leaky pointer, since we were holding a reference to browser context, it will therefore be destroyed at the end of everything and messes with the cleanup process.
This also Fixes #8754 , geolocation service has its own dedicated thread, the response from
AtomAccessTokenStore
were being sent back to IO thread instead, hence the UI freezed.