Did Javascript Bridge support for QWebEngine make it into 5.5?

[RolandHughes]

All,

I cannot tell from this feature list http://wiki.qt.io/New_Features_in_Qt_5.5 if the javascript bridge feature made it into QWebEngine. Ok, technically it was called the WebKit bridge http://doc.qt.io/qt-5/qtwebkit-bridge.html but I found various posts that a WebEngine version was being worked on for 5.5. I just cannot tell from the list if it actually made it.

Did A WebEngine bridge get built?

thanks,

[anda_skoa]

There is a new mechanism for accessing application objects from web content: http://doc.qt.io/qt-5/qwebchannel.html

Even works with websockets and an external browser.

Cheers,
_

[RolandHughes]

Anda,

I know about WebChannel. While it could be made to work it didn't fit the bill as well as the bridge. This app has a massive common chunk of html5 and javascript which works for all platforms and the browser/kiosk type application is currently custom on each target. Right now only one target is being done with Qt and it is the last target. The others were all done with different tools. I wasn't here at the beginning to architect, so no need to point out the obvious.

Despite the obvious, the thousands and thousands and thousands of lines of complicated back end stuff has, by my count, less than 30 lines (some of which are only comments) specific to any target. None of that target specific code attempts to load anything which would not be found natively on all targets or wasn't custom written for the package. In short, I have to hand it to the kids who did all of that without an architect because they did a mighty fine job. Asking that group bundle in qwebchannel.js which would be used on only one target and dead weight on all others is something I would like to avoid.

No, cross compiling the Qt app for all other targets isn't a conversation which can be had. Especially since Qt doesn't have support for some of the targets, many yes, but not all.

I thank you for your time though.

I was just hoping they got farther than QWebChannel

[anda_skoa]

I am afraid I don't follow.

The WebKit bridge allowed the web engine's JavaScript environment to access objects exported from the C++ part of the application.
As does QtWebChannel.

On top of that QtWebChannel can even be used out-of-process, e.g. using a browser as the web UI side

Cheers,
_

[RolandHughes]

QtWebChannel requires a wart. The index.html file _must_ load qwebchannel.js at or very near the beginning. Either we would have to have a one-off-maintenance-disaster-waiting-to-happen index.html in the build universe -- or -- the dozens of other platforms would have to have qwebchannel.js included with their package and loaded in their browser even though it does them no good and could do them harm by colliding with something else.

The bridge did not require a big ugly wart to be included. It allowed for dynamic addition and the javascript could dynamically fall back after checking for capabilities, which it needs to do given the dozens of platforms (some of which Qt isn't even an _option_ on).

[anda_skoa]

Hmm, so the difference is that, behavior wise, the web engine bridge did pre-load the equivalent of qwebchannel.js?

I am not really into the web technologies, but can't you do the same by loading an "environment page" using setHtml() which then loads the actual content?

Cheers,
_

[RolandHughes]

Hmm, so the difference is that, behavior wise, the web engine bridge did pre-load the equivalent of qwebchannel.js?

I am not really into the web technologies, but can't you do the same by loading an "environment page" using setHtml() which then loads the actual content?

Cheers,
_

In theory, provided we didn't clobber anything and the index.html file didn't get horribly complex. The bridge approach was cleaner. Only two teams had to be coordinated for an injection approach. The C++ developers and the Javascript developers. Adding a file requires coordinating 4-5 teams because now source control, build, deployment, and static html groups all have to be involved. At any rate, late last night they opted to go with the webchannel route because the cheat of using the title and clipboard was going to be limiting potential enhancements down the road.

Let the slow journey begin.

[anda_skoa]

Hmm, I don't see why more teams would be involved, the C++ team would be the one providing the injection.

Not that this is relevant now, but even if QtWebEngine had the web channel built in, the other browsers wouldn't so the shared HTML/JavaScript would not be able to access any of the bridge's objects anyway, no?

Cheers,
_

[RolandHughes]

Hmm, I don't see why more teams would be involved, the C++ team would be the one providing the injection.

Not that this is relevant now, but even if QtWebEngine had the web channel built in, the other browsers wouldn't so the shared HTML/JavaScript would not be able to access any of the bridge's objects anyway, no?

Cheers,
_

Ahhh, you don't work with large places that have departments in charge of things. When you add a file to a controlled project each of those departments have to be involved. The bridge allows the C++ developer to direct inject functions via existing modules. The javascript people already have mechanisms to test for functions based on platform in their existing source. Even more people have to get involved when it is a text file which could be hacked with any text editor.

Direct injection via bridge is secure. A binary thumps it in. The only thing which can get changed by someone being evil is if the function gets called. The function already defends against garbage.

While I would never consider Windows a secure platform, that team went the direct injection route with their toolset just to try and lock a bit more down.

[anda_skoa]

The bridge allows the C++ developer to direct inject functions via existing modules.

But that's the same thing for calling setHtml() in the webview
This is C++, no?

Cheers,
_

[RolandHughes]

But that's the same thing for calling setHtml() in the webview
This is C++, no?

Cheers,
_

Yes, it is C++. No, it is not the same.