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.
We are going to use IPC_MESSAGE_HANDLER_DELAY_REPLY to handle
synchronous messages but DictionaryValue is not copyable, so we pass the
JSON string instead.
It's possible that the object gets destructed after reloading, however
since we already released all objects in browser when unloading, it
would cause troubles when sending message in an unexist context. We just
rely on the closure to mark whether the context is gone.
A more suitable solution, however, is to restart renderer process when
doing reloading.
The process object is created under node context, and it will live
through the reloading, so we are responsible for clearing the listeners
to make sure resources are not leaked.
It seems that it's avoidable to make callback cross-process when we
start to emitting events for GUI elements, without this feature our
implementation will be much more complicated. I will find a way to warn
about resources leak in browser.
Now it's forbidden for browser to store reference to objects (including
functions) in renderer, because when the renderer is destroyed, it's
extremely hard to clean all of corresponding objects in browser
correctly, which would cause very bad resources leak.
Now, when creating a remote object in renderer, the browser will
reference the corresponding object by storing it in a strong map. And
when the remote object in renderer is GCed, the corresponding object
will be dereferenced in browser.
Basic usage is:
remote = require 'remote'
Window = remote.require 'window'
w = new Window { width: 800, height: 600 }
Still need to do:
* Beter support for Array type.
* Remote objects should cheat devtools.
* Support cross-process callbacks.
