Qt WebKit2 doesn't contain API for QML apps to clear memory or application caches nor local storage. The functionality is already implemented to WebKit2, but need to be exposed to QML apps also.
Created attachment 171390 [details] [Qt][WK2] Add QML API to clear memory caches and local storage
Comment on attachment 171390 [details] [Qt][WK2] Add QML API to clear memory caches and local storage You need to set r? and cq? if you'd like your patch to be reviewed and landed. LGTM otherwise.
(In reply to comment #2) > (From update of attachment 171390 [details]) > You need to set r? and cq? if you'd like your patch to be reviewed and landed. LGTM otherwise. Thanks
Comment on attachment 171390 [details] [Qt][WK2] Add QML API to clear memory caches and local storage This is going to clear the caches on all the pages, which might be misleading since it's called on a page instance. I'm not too sure how we should address this as we don't have any all-page API yet, we should be looking at it once we released Qt 5.0. If you don't need this API now somehow I think it would be better to wait until we have a proper solution. I'm setting it r- for now because I think that this should not be the final solution, tell me if you have further ideas.
(In reply to comment #4) > (From update of attachment 171390 [details]) > This is going to clear the caches on all the pages, which might be misleading since it's called on a page instance. I'm not too sure how we should address this as we don't have any all-page API yet, we should be looking at it once we released Qt 5.0. So should this be part of the WebContext for example?
(In reply to comment #4) > (From update of attachment 171390 [details] [details]) > This is going to clear the caches on all the pages, which might be misleading since it's called on a page instance. I'm not too sure how we should address this as we don't have any all-page API yet, we should be looking at it once we released Qt 5.0. Good point. One approach would be to create QWebCacheManager class which would handle the cleanup and expose access to it through QQuickWebViewExperimental. And then later on change the access to be part of the all-page API once that's available?
We had plans to expose the WebContext in QML at some point but it wasn't easy to decide if we would require any WebView to be created within a WebContext, if a WebView could create its own default WebContext, etc. so we decided not to expose it. Most QML items should either affect the display or input events. Though we would need a similar mechanism to support static settings in QWebSettings in WebKit2 like storage paths. One quick idea is to have a QtWebKit global object, similar to the Qt object ( http://doc.qt.digia.com/qt/qdeclarativeglobalobject.html ) and within there expose context/global functions. This assumes that we support only one WebContext at a time which is something we didn't agree to yet. This is just an example and I haven't tried it myself, maybe it's not even possible to let the QtWebKit import add anything to the global object. But all this is a bit out of the focus of the team at the moment and any such change shouldn't be done before we branched for 5.0.
=== Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.