RESOLVED INVALID 31953
[Qt] [code cleaning] Clean the code paths of QWebFrame::render()
https://bugs.webkit.org/show_bug.cgi?id=31953
Summary [Qt] [code cleaning] Clean the code paths of QWebFrame::render()
Benjamin Poulain
Reported 2009-11-28 08:53:11 PST
Some implementation of QWebFrame::render() check if the frame is valid, other don't. This check is done by QWebFramePrivate::renderPrivate() anyway: void QWebFramePrivate::renderPrivate(QPainter *painter, QWebFrame::RenderLayer layer, const QRegion &clip) { if (!frame->view() || !frame->contentRenderer()) return; so their is no need to check in QWebFrame.
Attachments
Remove the extra if() (1.34 KB, patch)
2009-11-28 08:58 PST, Benjamin Poulain
eric: review-
Check the view once. (2.35 KB, patch)
2009-11-28 10:09 PST, Benjamin Poulain
eric: review-
Benjamin Poulain
Comment 1 2009-11-28 08:58:38 PST
Created attachment 43982 [details] Remove the extra if()
Eric Seidel (no email)
Comment 2 2009-11-28 09:48:07 PST
Comment on attachment 43982 [details] Remove the extra if() This will crash grabbing ->frameRect()
Benjamin Poulain
Comment 3 2009-11-28 10:09:18 PST
Created attachment 43983 [details] Check the view once. Thanks Eric, I was working on something else and I did not think much this change. The modified patch does not clean much so I guess it's not worth it.
Eric Seidel (no email)
Comment 4 2009-11-29 07:43:20 PST
Comment on attachment 43983 [details] Check the view once. I'm not sure this is really any more clear. Especially it seems kinda strange to turn the if into an ASSERT in renderPrivate. I'd be OK with this if you were just cleaning up render(4 args) as you have, but it seems strange to change renderPrivate and rendner(QPainter*) too.
Benjamin Poulain
Comment 5 2009-12-01 00:10:39 PST
There is a refactoring of the painting code going on. This issue can be better addressed there.
Antonio Gomes
Comment 6 2009-12-01 02:46:04 PST
(In reply to comment #5) > There is a refactoring of the painting code going on. This issue can be better > addressed there. benjamin , bug # of this refactorying ? :)
Benjamin Poulain
Comment 7 2009-12-01 03:07:06 PST
(In reply to comment #6) > benjamin , bug # of this refactorying ? :) No bug yet. Kenneth and I are working on it. We will create a bug when something is working (should be soon).
Note You need to log in before you can comment on or make changes to this bug.