Feature Request: Method to send messages into HTML document

[Robert Schroll]

With QtWebKit, there were two ways to send messages into the HTML document: experimental.evaluateJavascript() and experimental.sendMessage(). As far as I can tell, neither of these exist in the new Ubuntu.Web. When an application contains a WebView to display part of its content, it can be very useful to have a side channel to pass messages between the QML part and the HTML part, short of reloading the WebView.

[Olivier Tilloy (osomon)]

There is a messaging API in oxide, but it’s not exposed in the Ubuntu.Web module. You can however import directly "com.canonical.Oxide 1.0" and use that if you need the messaging capabilities.

There is currently no documentation, but the oxide unit tests contain examples, see e.g. http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/view/head:/qt/tests/qmltests/api/tst_ScriptMessageRequest.qml and http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/view/head:/qt/tests/qmltests/TestUtilsSlave.js.

[Olivier Tilloy (osomon)]

Marking invalid as the feature is already present.

[José Serra (serrajv)]

I think that I could be usefull to have an equivalent to qtwebkit's experimental.evaluateJavascript or to webkitgtk's execute_script. As far as I concern Oxide Allows you to get acces to the DOM but no to the javascript "space" running in the WebKit instance, it allows you to execute javascript code but in another "space"

Is there a way in oxide to execute javascript code in the same space as the javascript that webview is executing? I mean that allows you acces to the javascript objects and variables been running in the webview instance.

[Olivier Tilloy (osomon)]

@José: this feature is absent from oxide’s API by design: exposing the entire QML JS context to a user script poses security issues.

However, message sending allows passing parameters, isn’t that enough for most purposes?

[José Serra (serrajv)]

I see... I'm looking for a workaround for a GUI using a local html file. Could I send a message to the webview current javascript including oxide.onMessage in the html file scripts? I haven't found a way to do that.

Send message has a context parameter what parameters admit?

Regards.

[Robert Schroll (rschroll)]

I've tried to call oxide.addMessageHandler() from within my HTML file, but I find that oxide isn't defined. Is there a setting in the WebView to tweak or a special JS file that has to be loaded by the HTML file to ensure that the oxide object exists?

[Olivier Tilloy (osomon)]

That’s not how it works: what you need to do is inject a UserScript into the document (usually when it’s fully loaded, but can also be injected before loading starts using greasemonkey metadata). This user script can install message handlers and send messages to the webview, and it also has normal access to the DOM.

See e.g. http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/view/head:/qt/tests/qmltests/TestWebContext.qml and http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/view/head:/qt/tests/qmltests/TestUtilsSlave.js.

[Robert Schroll (rschroll)]

I've finally managed to get this working. I haven't managed to get the user script to run in the same Javascript context that's actually in the WebView. (Perhaps there's a secret context value that enables this?) Instead, I have the user script create an event on the document, which I then catch with a handler in the HTML file. I've put it up as a Gist, in case anyone else wants to do this as well: https://gist.github.com/rschroll/5406e95d8b008736852c

Is there a less silly way to accomplish this?

[Olivier Tilloy (osomon)]

> I haven't managed to get the user script to run in the same Javascript
> context that's actually in the WebView.

As I wrote in comment #4, that’s on purpose, sharing the same Javascript context would pose security issues.

> Is there a less silly way to accomplish this?

This doesn’t look silly, but it seems to me there’s an easier way to achieve that: you can modify the DOM from within the user script directly, without having to have it send a message to the document and handle it in the HTML file. So your user script (oxide-user.js) would look like this:

  oxide.addMessageHandler("MESSAGE", function (msg) {
      document.body.innerHTML += "<p>Message received. You said " + msg.args.greeting + "</p>";
      msg.reply({str: "OK"});
  });

and you wouldn’t need the <script> tag in oxide-test.html.

[Robert Schroll (rschroll)]

> As I wrote in comment #4, that’s on purpose, sharing the same Javascript context would pose security issues.

But evaluateJavascript, for example, doesn't expose the entire QML JS context to the the HTML JS context -- it merely tells the HTML JS context to eval a string in its own context. I could implement it within my previous example. My complaint isn't that we don't have enough power, it's that it's inconvenient and not discoverable.

> you can modify the DOM from within the user script directly, without having to have it send a message to the document and handle it in the HTML file.

Ok, I've committed the cardinal sin of tech support by not telling you what I'm *really* doing. What I want is for some action in the QML environment to trigger some code in a library loaded in the WebView. (In my case, that's the Monocle library for rendering ebooks.) So I really do need to get to the JS context inside the WebView; doing DOM manipulation in the user script context doesn't cut it.

Thanks for you help on this issue. I realize this isn't the proper place for tech support, and I appreciate the time you've spent to help me understand what's going on.

[José Serra (serrajv)]

I will use Robert's solution, thank you Robert.

And thanks Olivier too for your clarifications about this issue.

Regards.