Here’s the weekly summary of the Qt related changes that landed in WebKit trunk this week:
- Daniel and Robert added support for the XSS auditor to the Qt DRT (33419).
- Simon removed unnecessary memory allocations of QPainterPath from WebCore::Path (33466).
- Zoltan continued to make the world a subclass of
FastMallocBase. - Diego fixed support for user stylesheet locations in the Qt DRT (33617).
- Andreas fixed the scrolling performance on pages with embedded widgets (33373).
- Jocelyn reworked the qmake based build system to separate the generated files from the regular build, fixing longstanding dependency issues (33542).
- Diego added a missing implementation of
fileSystemPath()to the Qt build of KURL (33614). - Jakub fixed a bug with XSL stylesheet loading.
- Ben fixed support for touch events in
document.createEvent()(33605) as well as the detection of touch events as user gestures (33597). - Kim fixed support for touch event coordinates in zoomed and scrolled pages (32899).
- Petri fixed an incorrect touch layout test (33465).
- The Szeged hackers continue to rock our world by keeping the bot green green green!
That’s all for this week, folks 
. If I have missed anything or you’d like to mention something in the next digest, please send me an email.
BTW, if you’d like to join the development, please subscribe to the webkit-dev and the webkit-qt mailing lists. You can also join our weekly meeting point on IRC in #qtwebkit on freenode every Monday at 15:00. There’s no fixed agenda, but instead there’s a good chance that most developers will be around, if you’re looking for code reviews, etc. in a particular area. See you there!
Possibly related posts:
10 comments
Thanks for your update. May I know if you have any plan to address the issue with WebKit plugins such as Flash, Java, etc which cannot be painted/printed/exported to images or pdf? This seems to be an issue since Qt 4.4 in 2008 which has not been addressed. Please kindly advise. Thank you.
Moreover, whenever I print pdf from WebKit, all the hyperlinks are lost. A patch has been suggested: http://code.google.com/p/wkhtmltopdf/issues/detail?id=39
@simpleit:
“Moreover, whenever I print pdf from WebKit, all the hyperlinks are lost. A patch has been suggested: http://code.google.com/p/wkhtmltopdf/issues/detail?id=39”
That’s strange – the bug is marked as fixed, but I’m sure the patch in question was (rather unhelpfully) rejected out of hand:
http://qt.gitorious.org/qt/qt/merge_requests/1733
Or maybe the rejected patch implements a generalised version … ?
@simpleit
About the printing problem, what if you print from a QGraphicsWebView?
It make sense not to be able to print the plugins when they are windowed, but I guess it should work with windowless plugins…
Do you have a bug open on bugzilla?
@anon
Apparently, it has been fixed in trunk (http://github.com/antialize/wkhtmltopdf/commit/95770637926a2b362e3c7be9424ba70d0fbfaf24 ) but the fix depends on http://qt.gitorious.org/qt/qt/merge_requests/1733
In trunk of wkhtmltopdf, the path making links in PDF is only used when __EXTENSIVE_WKHTMLTOPDF_QT_HACK__ is defined.
@Benjamin: Thank you for suggestion. I have not tried using QGraphicsWebView. Instead I printed/painted from QWebFrame::render & QWebFrame::print.
@Benjamin: I yet to open a bug on bugzilla.
I tried with QGraphicsWebView, QGraphicsScene & QGraphicsView to render via QGraphicsScene::render but the outcome was the same: No flash & java plugins.
When I load page with Flash I see these lines from console:
plugin,NP_Initialize start
plugin,NP_Initialize end
plugin,NP_GetEntryPoints start
plugin,NP_GetEntryPoints end
NP_Shutdown
Debugger() was called!
And then the program starts rendering to image/pdf. I guess the plugin was shut down before the rendering started. How to make sure that the rendering is done before the flash is shut? Thanks.
@simpleit
Then I guess it is a good time to open a bug report and start working on it
Comments on this entry are closed.