| 2014-03-26 00:09:29 |
Chris Coulson |
description |
Originally, I intended for the default WebContext (the one that's created automatically for WebView's that don't have an explicit context set) to be hidden away from QML, with some basic configurability proxied via the "Oxide" singleton. If developers wanted to use advanced features, they could create an explicit WebContext.
However, there are going to be some issues with this approach:
- We're adding more and more stuff to WebContext, and this stuff needs to be duplicated.
- Due to some limitations in Chromium, multiple WebContext's do not work correctly in single process mode because all RenderView's run in the same in-process RenderProcess, which maps to a single BrowserContext (and hence WebContext). The implication of this is that any IPC messages from any views that are destined for a specific WebContext will end up always being delivered to first WebContext, which might not be the right one. If we want to support a single process mode, we don't want developers having to create additional WebContext's in order to use things like user scripts.
We should make the default WebContext singleton available to QML. Currently, WebContext.dataPath and WebContext.cachePath are construct-only properties because they can't be changed once the BrowserContext has been created internally. If we are going to expose the default WebContext singleton to QML, we will need to lazy construct the BrowserContext in order to be able to change dataPath and cachePath on a fully-constructed (but not yet in-use) WebContext. |
Originally, I intended for the default WebContext (the one that's created automatically for WebView's that don't have an explicit context set) to be hidden away from QML, with some basic configurability proxied via the "Oxide" singleton. If developers wanted to use advanced features, they could create an explicit WebContext.
However, there are going to be some issues with this approach:
- We're adding more and more stuff to WebContext, and this stuff needs to be duplicated.
- Due to some limitations in Chromium, multiple WebContext's do not work correctly in single process mode because all RenderView's run in the same in-process RenderProcess, which maps to a single BrowserContext (and hence WebContext). The implication of this is that any IPC messages from any views that are destined for a specific WebContext will end up always being delivered to the first WebContext, which might not be the right one. If we want to support a single process mode, we don't want developers having to create additional WebContext's in order to use things like user scripts.
We should make the default WebContext singleton available to QML. Currently, WebContext.dataPath and WebContext.cachePath are construct-only properties because they can't be changed once the BrowserContext has been created internally. If we are going to expose the default WebContext singleton to QML, we will need to lazy construct the BrowserContext in order to be able to change dataPath and cachePath on a fully-constructed (but not yet in-use) WebContext. |
|
