Summary: | [Qt] Avoid calling QWebPage's virtual functions during deletion of QWebPage | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Arunprasad Rajkumar <arurajku> | ||||||||||
Component: | WebKit Qt | Assignee: | Nobody <webkit-unassigned> | ||||||||||
Status: | RESOLVED INVALID | ||||||||||||
Severity: | Critical | CC: | allan.jensen, ararunprasad, hausmann, jose.lejin, jturcotte, noam | ||||||||||
Priority: | P2 | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | All | ||||||||||||
OS: | All | ||||||||||||
Attachments: |
|
Description
Arunprasad Rajkumar
2013-08-10 07:36:43 PDT
Created attachment 208476 [details]
Patch
Since QWebPage is already a wrapper around QWebPageAdaptor why can't you call QWebPageAdaptor::preparetoDestroy() from the qwebpage destructor? (In reply to comment #2) > Since QWebPage is already a wrapper around QWebPageAdaptor why can't you call QWebPageAdaptor::preparetoDestroy() from the qwebpage destructor? When control reaches ~QWebPage derived class already been destroyed(~UnLoadTestPage). (In reply to comment #3) > (In reply to comment #2) > > Since QWebPage is already a wrapper around QWebPageAdaptor why can't you call QWebPageAdaptor::preparetoDestroy() from the qwebpage destructor? > > When control reaches ~QWebPage derived class already been destroyed(~UnLoadTestPage). True, but that only matters if you need the overloaded alert like the test-case. Most common cases of what happens on unload would work, wouldn't it? (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Since QWebPage is already a wrapper around QWebPageAdaptor why can't you call QWebPageAdaptor::preparetoDestroy() from the qwebpage destructor? > > > > When control reaches ~QWebPage derived class already been destroyed(~UnLoadTestPage). > > True, but that only matters if you need the overloaded alert like the test-case. Most common cases of what happens on unload would work, wouldn't it? Nevermind that was the entire case of the bug-report. If this depends on the user of qwebpage calling an extra method, could he call something to unload the page instead? Perhaps mainFram()->setHtml("") ? (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #2) > > > > Since QWebPage is already a wrapper around QWebPageAdaptor why can't you call QWebPageAdaptor::preparetoDestroy() from the qwebpage destructor? > > > > > > When control reaches ~QWebPage derived class already been destroyed(~UnLoadTestPage). > > > > True, but that only matters if you need the overloaded alert like the test-case. Most common cases of what happens on unload would work, wouldn't it? > > Nevermind that was the entire case of the bug-report. > > If this depends on the user of qwebpage calling an extra method, could he call something to unload the page instead? > > Perhaps mainFram()->setHtml("") ? Thanks Allan, I tried this, it is not working. Might be because of its async. nature of mainFrame()->setHtml() I guess :( (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > (In reply to comment #2) > > > > > Since QWebPage is already a wrapper around QWebPageAdaptor why can't you call QWebPageAdaptor::preparetoDestroy() from the qwebpage destructor? > > > > > > > > When control reaches ~QWebPage derived class already been destroyed(~UnLoadTestPage). > > > > > > True, but that only matters if you need the overloaded alert like the test-case. Most common cases of what happens on unload would work, wouldn't it? > > > > Nevermind that was the entire case of the bug-report. > > > > If this depends on the user of qwebpage calling an extra method, could he call something to unload the page instead? > > > > Perhaps mainFram()->setHtml("") ? > > Thanks Allan, I tried this, it is not working. Might be because of its async. nature of mainFrame()->setHtml() I guess :( Another option might be to only introduce the close or unload method on qwebpage level and call QWebPageAdapter::deletePage(). I think it will do the same, but using the iterative detach/closeURL in FrameLoader. Some review comments given by Allen(via IRC) - Implement the unload() method QWebFrame instead of QWebPage - Use detachFromParent()/cancelAndClear() of FrameLoader to send unload event instead of closeURL() - Finding appropriate place to call QWebFrame::unload implicitly without user intervention(may be side-effect of QWidget::close,..or similar) Allan, Please correct me if I'm wrong :) Created attachment 208566 [details]
Patch
(In reply to comment #9) > Created an attachment (id=208566) [details] > Patch Allan, I feel calling unload implicitly from ~QWebViewPrivate & ~QGraphicsWebViewPrivate is more reasonable than closeEvent. What do you think? Created attachment 208648 [details]
Patch
(In reply to comment #11) > Created an attachment (id=208648) [details] > Patch Called unload() method implicitly from QWebViewPrivate::detachCurrentPage() & QGraphicsWebViewPrivate::detachCurrentPage(). So QtWebKit embedder uses QWebView/QGraphicsWebView, deletion of those will trigger unload() without any extra call. Created attachment 208823 [details]
Patch
(In reply to comment #13) > Created an attachment (id=208823) [details] > Patch As per your review comments added API test for QGraphicsWebView::close, QWebView::close and history count checking after unload. (In reply to comment #14) > (In reply to comment #13) > > Created an attachment (id=208823) [details] [details] > > Patch > > As per your review comments added API test for QGraphicsWebView::close, QWebView::close and history count checking after unload. I tried with load(QUrl()), it worked. Thanks Allan & Jocelyn :) I think using same fix http://trac.webkit.org/r61433 workaround can be removed. Isn't it? Since calling mainFrame()->load(QUrl()) before deleting a custome WebPage object works as expected, I'm closing this bug. Comment on attachment 208823 [details]
Patch
Removing flags.
|