On 1 November 2017 at 15:23, Andrea Giammarchi <andrea.giammar...@gmail.com>
wrote:

> so ... it looks really like the exposed API is completely useless as it is
>
> ```js
> webkit.messageHandlers.gjs.postMessage('hello');
> ```
>
> Returns a
>
> [boxed instance proxy GIName:WebKit2.JavascriptResult jsobj@0x7fa08c2e4160
> native@0x7fa052081d80]
>
>
> and if you try to get its value it goes bananas with a message like:
>
> Gjs-WARNING **: JS ERROR: Error: Unable to find module implementing
> foreign type JavaScriptCore.Value
>
>
> What's the purpose of register_script_message_handler at all? What am I
> missing?
>
>
Andrea, this is the problem Philip raised earlier and I replied to. I use
this library to solve the problem: https://github.com/
saifulbkhan/wkjscore-result

  7 import * as WkJsCore from '../../gjs/WkJsCore'
...
 85         let contentManager = this.webkit.get_user_content_manager();
 86         if
(!contentManager.register_script_message_handler('slinternal')) {
 87             throw "register_script_message_handler() failed";
 88         }
 89         contentManager.connect("script-message-received::foobar", (obj,
jsResult) => {
 90             let wkResult = WkJsCore.Result.new(jsResult);
 91             let str = wkResult.process_result_as_string();


Unfortunately JavaScriptCore doesn't provide it's own GIR API to access the
JS data :(


>
>
> On Wed, Nov 1, 2017 at 11:02 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I've quickly provided a proof of concept but you could have a JSONChannel
>> class singleton on the client side that queue each info and wait for the
>> GJS side to receive one before sending another.
>>
>> I might try a real implementation though and see how it works.
>>
>> however, this is just a work around for the fact you can send messages
>> without any content (... and I wonder how that can be useful in any way ...)
>>
>> Regards
>>
>> On Wed, Nov 1, 2017 at 10:50 AM, Sam Jansen <sam.jan...@starleaf.com>
>> wrote:
>>
>>>
>>>
>>> On 1 November 2017 at 11:55, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>>> Actually the `notify::title` with a prefixed "secret-channel" and
>>>> serialized JSON looks like the best of them all, for the time being, as it
>>>> makes it straight forward for both client and server to communicate.
>>>>
>>>> ```js
>>>> // listen to each response
>>>> new MutationObserver(m => {
>>>>   if (/^secret:response=/.test(document.title)) {
>>>>     const data = JSON.parse(document.title.slice(RegExp['$&'].length));
>>>>     document.title = '';
>>>>     console.log(data);
>>>>   }
>>>> }).observe(
>>>>   document.querySelector('title'),
>>>>   {childList: true}
>>>> );
>>>>
>>>> // send info using client or simulate server sending in responses
>>>> document.title = 'secret:response=' + JSON.stringify({some: 'value'});
>>>> ```
>>>>
>>>> with a proper class/wrap to handle events and send data transparently
>>>> it might be a great way to exchange info
>>>>
>>>>
>>> I've just come to the opposite conclusion, though I don't disagree as
>>> such...
>>>
>>> My concern is that setting document.title, and having notify::title
>>> called is asynchronous (I believe). So in your JS, if one had:
>>>
>>> ```
>>> document.title = '1'
>>> document.title = '2'
>>> ```
>>>
>>> Then by the time notify::title is called, and you inspect your
>>> "webkit.title" property, I'd expect you'd only see the '2' value, and
>>> (likely) not the '1'.
>>>
>>> It's possible to solve this by ensuring the GJS side has picked up a
>>> message, and e.g. reset the title, I suppose. This feels like an awkward
>>> solution to me though.
>>>
>>>
>>>>
>>>>
>>>> On Wed, Nov 1, 2017 at 5:53 AM, Sam Jansen <sam.jan...@starleaf.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 1 November 2017 at 05:43, <philip.chime...@gmail.com> wrote:
>>>>>
>>>>>> On Thu, Oct 12, 2017 at 5:23 AM Andrea Giammarchi <
>>>>>> andrea.giammar...@gmail.com> wrote:
>>>>>>
>>>>>>> FWIW I've used the location with a private channel as protocol to
>>>>>>> intercept calls to/from the page and GJS.
>>>>>>>
>>>>>>> https://github.com/WebReflection/jsgtk-twitter/blob/master/a
>>>>>>> pp#L162-L175
>>>>>>>
>>>>>>> The channel is a random string: https://github.com/Web
>>>>>>> Reflection/jsgtk-twitter/blob/master/app#L59
>>>>>>>
>>>>>>> From the page, which is aware of the "secret" channel, I call GJS
>>>>>>> actions via location.href = `secret1234:method(${encodeURI
>>>>>>> Component(JSON.stringify(value))})`;
>>>>>>>
>>>>>>> The protocol secret1234 is intercepted and the
>>>>>>> `controller.method(JSON.parse(decodeURIComponent(restOfURI)))`
>>>>>>> invoked.
>>>>>>>
>>>>>>> To signal the page everything is fine I use
>>>>>>> this.webView.runJavaScript https://github.com/WebReflect
>>>>>>> ion/jsgtk-twitter/blob/master/app#L377
>>>>>>>
>>>>>>> The page has a listener for the `secret1234` event on the main
>>>>>>> window, and such listener is instrumented to react accordingly with the
>>>>>>> CustomEvent .detail payload/info.
>>>>>>>
>>>>>>> This might look a bit convoluted, and it has JSON serialization as
>>>>>>> limitation for the kind of data you want to pass (i.e. I use base64 
>>>>>>> encoded
>>>>>>> images as source from remotely fetched files enabling somehow CORS for
>>>>>>> whatever I want) but it worked well, circumventing the missing
>>>>>>> communication channel available in Qt.
>>>>>>>
>>>>>>> Maybe today there are better ways for doing a similar thing and if
>>>>>>> that's the case, please share.
>>>>>>>
>>>>>>
>>>>>> Here is another, fairly new, way to do it. Start out by registering a
>>>>>> "script message handler":
>>>>>> http://devdocs.baznga.org/webkit240~4.0_api/webkit2.usercont
>>>>>> entmanager#method-register_script_message_handler
>>>>>>
>>>>>> To send a message to the page, use the same thing that Andrea uses:
>>>>>> http://devdocs.baznga.org/webkit240~4.0_api/webkit2.webview#
>>>>>> method-run_javascript
>>>>>>
>>>>>> To send a message from the page to the GJS program, use the
>>>>>> postMessage() method mentioned in the documentation, and connect to this
>>>>>> signal in your GJS program to receive the message:
>>>>>> http://devdocs.baznga.org/webkit240~4.0_api/webkit2.usercont
>>>>>> entmanager#signal-script-message-received
>>>>>>
>>>>>>
>>>>> Excellent - I had not noticed this. My first attempt at communicating
>>>>> between WebKit2 and GJS was via setting "document.title" and having GJS
>>>>> connect to the "notify::title" signal! Not a great approach, this looks
>>>>> much better.
>>>>>
>>>>>
>>>>>> Although I just realized that unfortunately the values won't be able
>>>>>> to be marshalled into GJS since you need to use the JavaScriptCore API to
>>>>>> get at them. This is a really nice method in C, but in JS you can only 
>>>>>> use
>>>>>> it to send a message without any content. That is annoying. I should
>>>>>> probably open up an issue about this.
>>>>>>
>>>>>>
>>>>> I just hit upon this problem myself. In researching it, I found it is
>>>>> solved (at least well enough for my use-case) with this open source 
>>>>> library:
>>>>>
>>>>> https://github.com/saifulbkhan/wkjscore-result
>>>>>
>>>>> It's awkward having another dependency for me, especially one that
>>>>> isn't in a normal Ubuntu/Fedora/etc. package, but otherwise this approach
>>>>> worked fine for me.
>>>>>
>>>>>
>>>>>> On Wed, Oct 11, 2017 at 12:57 PM, Adriano Patrizio <
>>>>>>> adriano.patri...@hotmail.com> wrote:
>>>>>>>
>>>>>>>> Thank you for response, this is my problem: have necessity to
>>>>>>>> implement methods into my web application webkit2 based and comunicate 
>>>>>>>> with
>>>>>>>> GJS script (example: filesystem functions to read and write files or 
>>>>>>>> window
>>>>>>>> managment).
>>>>>>>>
>>>>>>>
>>>>>> Regards,
>>>>>> Philip C
>>>>>>
>>>>>> _______________________________________________
>>>>>> javascript-list mailing list
>>>>>> javascript-list@gnome.org
>>>>>> https://mail.gnome.org/mailman/listinfo/javascript-list
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
javascript-list mailing list
javascript-list@gnome.org
https://mail.gnome.org/mailman/listinfo/javascript-list

Reply via email to