@JonBI don't know if that's the problem, but I downloaded the QWebView module using the maintenance tool but still QtCreator does not recognize it as an existing module.

@kumararajas said in QWebView - On Click CPU Performance: Thank you @Konstantin-Tokarev This explanation means a lot. This helps us to understand that we are using older version of Qt WebKit and which is not really efficient. At this moment of time, we don't have a plan to update to the latest version. We will have to find a work around in the application to manage the situation. Does it mean that you cannot change any bits of software in your system and you are limited to workarounds on the side of web page? If so, it's really sad situation. If you are able to change software, you are strongly adviced to use QtWebKit 2.3.4, or at least give it a try. @kumararajas said in QWebView - On Click CPU Performance: @Konstantin-Tokarev Yes, we have been trying to understand who consumes the lot of CPU and why. When I did profiling using gprof/perf tools, I can find out that which function in my application consumes a lot, but that does not root in to the framework, which is webkit. Do you recommend any method which I can profile the framework side as well? Don't use gprof. This tool claims to measure time spent in functions, but in fact measures totally different thing. And, as you've already discovered, it can only profile code which was rebuilt with -pg flag. As for perf, it is decent tool. On older systems oprofile can be used. Make sure that your QtWebKit library is not stripped And even if we find issues in the framework, at this moment we are not in a position to upgrade the system. So we will identify the work around and live with it ( Already found couple of work around solution, which I will be sharing it in a while here ) I have no idea what do you mean here, and I don't really want to be in your shoes. (/me once had to reverse engineer and then binary patch 3rd party kernel driver with no source code, but at least there were no problems with updating target system) Reason for asking such question is, Someone might have faced similar problem and might have the ready solution. Instead of I spending lot of time in exploring, researching, debugging, etc, I could post it here to know if someone knows about it. However, in parallel to posting this question, I have been doing things in parallel if in case I don't get the answer. For this post, you being a legend on webkit, you have mentioned that it could be a problem of webkit version that we use, which makes sense and unveils the root cause. I'm far from being legend, and there may be other reasons of high CPU consumptions, maybe several factors at once. It can be that WebKit just doesn't have enough memory to process page, and system is thrashing (you'll see high sys usage in top then). When I touch the report, does Qt Web Kit renders the whole web page again? If you are not using QWebSettings::TiledBackingStoreEnabled and are not using accelerated composting on QGLWidget viewport, and are not using QWebPage::setPreferredContentsSize, then QtWebKit definitely reners whole page again after scroll. It doesn't redraw old pixel, but it performs whole rendering procedure with QPainter being clipped to update region. It may easily be a bottleneck if page is complex

@ShivaHaze @ShivaHaze said in 'evaluateJavaScript()' doesn't return any value. (content position on page wanted): You are a god to me - Thanks so much! I think you might have meant "good" rather than "god" ;-) I am very pleased this approach has worked for you. It is potentially useful for me to know for my own work one day. Had I realized you had not tried the "delay" principle earlier, we would have got there quicker. The actual implementation of the delay loop is "naughty". It will mean that your application is "running busily" (i.e. using CPU time, potentially blocking other applications) for most of 1 second. If an expert here looks at it, please don't shout at me! Like I said, I got it from elsewhere as "quick & dirty". For your purposes it's probably fine, and we achieved it without you having to do slots & signals which you were not keen on learning at this stage. If you feel like you want to improve/experiment, in the same stackoverflow thread have a look at https://stackoverflow.com/a/3756341/489865, leveraging QWaitCondition, whose description sounds like it should have the same effect without the "busy blocking": class SleepSimulator{ QMutex localMutex; QWaitCondition sleepSimulator; public: SleepSimulator::SleepSimulator() { localMutex.lock(); } void sleep(unsigned long sleepMS) { sleepSimulator.wait(&localMutex, sleepMS); } void CancelSleep() { sleepSimulator.wakeAll(); } }; Certainly I would try it. If you copied that class into your code, you would call it (I assume) via: SleepSimulator* sleep = new SleepSimulator(); sleep->sleep(1000); delete sleep; Now I think you can get down to the real coding you want to do for your application! Best of luck.

@mousemao I've made a feature request here https://bugreports.qt.io/browse/QTBUG-55074 BTW, 大哥，你好~~

@Shidharth Maybe you can extract a QWebElement and insert it into a separate QWebView and use print(). But i think it may not look the same as in the origin QWebView. Also maybe there is a possible JavaScript way?

Then it's rather QNetworkAccessManager that should be of interest.

Indeed, WebKit has been deprecated and won't, therefore, be shipping with the forthcoming Qt 5.6. However, you can still build from source (or, at least, you should still be able to build it from source). As a general rule, new projects ought to use WebEngine, but because there isn't yet a 1:1 correspondance between WebEngine and WebKit (is there ever going to be?!), you might have no choice but have to use WebKit for the time being. (I am in that boat too, i.e. WebEngine is currently missing too many things to make it possible for me to drop WebKit -- I tried! --. Yet, I can't see myself building WebKit from source, so I am not going to upgrade to Qt 5.6. In the end, I really wish Qt would release binaries for WebKit. Not as part of Qt 5.6 since it's going to be an LTS, but at least on the side so many people (I am sure) don't feel like their only options are either to build WebKit from source (!!) or stick to Qt 5.5.)

Hi, QtWebKit was not available on Android either, it's one of the platform that, with iOS, doesn't allow third party web engines. You can use the QtWebView module for these platforms. That will provide you a native web view to use.

Hi @maximo, did you have success with the MacNativeWidget and didi it reach your requirements.

I fixed it like so: Comment out the default w.show() in my main.cpp. I created a Q_INVOKABLE class method on main window called showAppWindow() that merely does a this->show(). I did the steps to inject my C++ object (called cpp) into my Javascript via the C++ <==> Webkit bridge. In my index.html file, at the bottom before the ending BODY tag, I added this: <script type="text/javascript"> try { if (cpp) { setTimeout('cpp.showAppWindow();',100); } } catch(e){} </script>

@Dave-F You're Welcome :) Then you can use QWebEngineUrlRequestInterceptor I guess.

@maximo Did you finally submit an app to the Mac App store and which web incarnation of Qt did you use ?

I found the solution. Not only can you call the HTML5 postMessage() API to pass messages back and form from/to the IFRAME to the parent document, but Qt's version of WebKit have lax security controls compared to Chrome and do allow you to do the following in the IFRAME's Javascript. The trick is the window.parent.[whatever] -- something that Chrome won't let you do with stuff accessed with file:// (local files). $(document).ready(function(){ if (window.parent.cpp) { var cpp = window.parent.cpp; // do something with C++ here through the cpp object } });

I solved this. I moved everything related to the serial port into a separate class SerialWorker and moved it to a separate thread. QThread* serialthread = new QThread; SerialWorker* serialworker = new SerialWorker(); serialworker->moveToThread(serialthread); connect(serialthread, SIGNAL(started()), serialworker, SLOT(InitSerialPort())); serialthread->start(); connect(serialworker, SIGNAL(NewProto(QByteArray)), this, SLOT(ProtocolInterpreter(QByteArray))); connect(this, SIGNAL(SendRS(QByteArray)) , serialworker, SLOT(writeData(QByteArray))); This works as supposed. Serial port is now more or less very responsive. WebKit is still blocking the GUI thread sometimes but thats not as much an issue as the serial port not responding.