Bug 282963 – Provide a mechanism for non-display loading and execution of web pages.

• Status: NEW
• Component: WebKit2

[Keith Ealanta]

Provide a mechanism for loading pages and running scripts on them without the full WKWebView rendering, possibly by allowing WebCore to be accessed directly.

Detail:
Sometimes a webpage can be relevant even with no display behavior.  This is particularly true now we have localStorage, IndexedDb etc.  These features are useful because they allow web-apps that can function when there is no connectivity.
Generally, Webit will be used in a full application context, but in modern mobile environments there are other operational contexts that may need access to the same data.  These include background tasks and notification handlers (no graphical context) and widgets (graphical context doesn't allow complex objects or most user input objects).  
In an ideal system there would be a way to load a page or run a script with the same operational context as a web-page.  This would then allow script operations on the site specific data.  This should not raise a security concern, as the same can be done invisibly where a full graphical context exists (i.e. with a WKWebView of size 0).  This would just allow the web infrastructure to be used in plces where graphics are meaningless/impossible

For context:
We have a mobile app that uses WKWebView.  It caches a lot of data in an IndexedDb, in particular to handle offline operation.
We want to create a Widget that uses the same data (and also background tasks and notification handlers).
A widget cannot attach a WKWebView to it's view tree (it can't use anything that inherits from Scrollable), and an unattached WKWebView appears to be non-functional.  Likewise, a background task has no view context so can't get a WKWebView to run.

Several solutions come to mind (listed in order of my idea of which is the best solution)
1. Provide a WKWebViewHeadless that operates like WKWebView, but without bothering about rendering to screen (might still include rendering for image-gen, tests, etc.)
2. Make the WebCore object accessible to developers, bypassing the rendering/presentation aspects of WKWebView.
3. Provide a way to access the data-stores by extending the capabilities of WKWebsiteDataStore to expose direct access to data in underlying stores (and to make sure the WKWebsiteDataStore can operate without attachment to a "live" WKWebView)
4. Provide a way to get the window object (i.e. access to DOM, modules etc) easily into the JavaScriptCore/JSContext object, with site connection so the dev can use direct JS queries against a site's data stores. (see above for why this isn't a security risk)
5. provide a way for an app to intercept/replace the storage paths from WebKit, so a common data store can be shared between the WebbApp and the Mobile App. This is defn. worst option (due to interface complexity) but might offer other advantages

[Keith Ealanta]

I'd happily look at doing this myself, but I have no understanding of the WebKit codebase, and I would need more ramp up support than it would take to fix it (not least of which - My C++ knowledge is 30 years out of date)

[Alexey Proskuryakov]

I believe that WebKitGtk already supports this. I don't think that there is interest from other ports at this time, but that can of course change in the future.

[Radar WebKit Bug Importer]

<rdar://problem/140165493>