From crash report this exists on OS X too, previously the fix is only
available on Linux. However we should remove all calls of protocol
things in UI thread in future.
In browser process, because of the use of v8::Locker in ProxyResolverV8,
creating HandleScope requires entering locker first, so in browser
process we should just use v8::Locker whenever we need to use V8 in a
callback called from non-V8 places (like dialog's callback, work pushed
to MessageLoop).
But also notice that the renderer process doesn't use v8::Locker, so we
have to be careful not to use it, otherwise blink would crash when
creating HandleScope.
It's not necessary to create HandleScope in v8 native binding functions,
because it's guarrenteed that the there is a upper HandleScope when the
native function is called. So unless we are urgent to free the handles,
not using HandleScope in native binding functions is a cleaner and safer
choice.
'finish-launching' is more like a OS X message name, and in atom-shell
it means initialization has done, so 'ready' seems to be a better name
and more easy to remember.
The 'will-finish-launching' event just represents the corresponding
message on OS X and is the same with 'ready' on other platforms, so we
keep its name to indicate that it's only useful for OS X specified
code.
Privously we release them when the window is unloaded, which is not
correct since a render view can have multiple windows (or js contexts)
and when the unload event is emitted the render view could already have
gone.
This PR does the cleaning work purely in browser, so here is no need to
worry about renderer's life time.
