https://bugs.kde.org/show_bug.cgi?id=363859
--- Comment #31 from Maik Qualmann <metzping...@gmail.com> --- Thanh, At the moment I have no real idea to solve it "elegantly". It could be a function that collects the results and then allocates the return values to the functions. Waiting is just a bit problematic and could make the geolocation GUI slow with slow internet connection. In principle, WebView now also "waits" for the result internally. I think this has time for later, much later. At the moment I would like to shrink the patch to make it easier to integrate it at compile time: 1. We do not need WelcomePageViewPage::WelcomePageViewPage class. QWebEngineView::page() should be enough. 2. At the moment we need a modified backend-googlemaps-js.js file for QWebEngineView. In the old QWebView, the messages are read via the status bar API. This function is no longer available on QWebEngineView. We send the messages now via the JavaScript console. I think we can do that with QWebView too, so we do not need duplicate code here. 3. There is a BUG (https://bugreports.qt.io/browse/QTBUG-43602) in QWebEngineView that has not been fixed yet. We have to intercept all mouse events via the child widget via an event filter. We can not do anything here. 4. We replace runScript() with setToScript() (no wait, because no return value from Java code) and getFromScript() (wait for return value with QEventLoop). We would not need to make any changes to backendgooglemaps.cpp if all JavaScript calls return a value, a "return true" is enough to leave the QEventLoop. Here then also a change to the backend-googlemaps-js.js file which would be valid for both browser engines. Maik -- You are receiving this mail because: You are watching all bug changes.
