WebDialog on Mac (call to Google SU engineers)

scottlininger

Hey Fredo,

As Rick said, this is a known bug to us, and a very annoying one. I wish I could say there's an easy workaround, but the behavior, I have been told via folks at Apple, is a fundamental WebKit problem. (We are still pursuing a fix.)

To answer your questions:

You're absolutely right.
There is not a simple workaround. The only way to make this work is to build your javascript code to be asynchronous. As you're probably discovering, this leads to JS code that is necessarily more complex. If you think of SU as a "server" that you're making asynchronous requests to, you can use code patterns that you might be familiar with from Ajax programming. You can build complex UIs this way, but it's not easy.
A fix for this is at the top of my personal list, but I do not expect a solution in time for SU7. No promises... but maybe we'll have a fix for an early maintenance release. Another thing we've considered is either building or working with the community to build a ruby/js bridge library that abstracts some of this, but it's just design discussions at this point.

Hope that helps. When SU7 goes live I'll be able to provide a more in depth discussion of this whole issue.

Cheers,

fredo6

Scott,Welcome to the forum. It's good to hear from the SU Google team, furthermore if you are specialist of the Ruby API.For the WebDialog issue on Mac, this is because Safari (Konqueror and Webkit actually) performs all redirections in asynchonous mode (so Window.location or anchor href jumps). On Windows / IE window.location is synchronous.I am surprised however that, despite of this, SU cannot do internally what you suggest the scripters shoudl do (which will be damned complex, because Ajax works mainly with HTTP requests, meaning that I don't know too much how you can support the skp: listener ; in addition Safari is known to have major issues with Synchronous requests). I may have found a workaround which I am testing currently. If this works, I'll tell you more.Note that this is in no way for very complex web dialogs. Just think of trapping key events typed in the web dialog. With the current Mac problem, you will only receive the last event (Key Up) when you type a key, all others being swallowed.I also suggest that for SU7, even if you can't fix the problem, you explore additional verbs like ElementSetValue, because most of the execute_script are actually just to put data in HTML forms. Also, would need to have extra APIs like GetSize and GetLocation.

Again, that was a genious idea to plug Javascript and web dialog box in SU / Ruby, but the current implementation of SU6 has really so many issues that I am not sure we'll see many scripts coming with WD.Fredo

mocathe1st

Hi All,

I've currently run into the synchronisation problem described above. The JavaScript file I have currently written is fairly simple, and only passes messages from Flash via JavaScript to Ruby. I've got a single function to take care of this. However, when I send a quick succession of messages from Flash to Ruby via JS most of the commands get lost on the Mac, this works fine on the PC.

I was just wondering if anyone found a solution to the synchronisation problem, is there a way to create a JavaScript buffer or a way of synchronising the messages?

Best Regards,
Malcolm Murray

chrisglasier

@mocathe1st said:

Hi All,

I've currently run into the synchronisation problem described above. The JavaScript file I have currently written is fairly simple, and only passes messages from Flash via JavaScript to Ruby. I've got a single function to take care of this. However, when I send a quick succession of messages from Flash to Ruby via JS most of the commands get lost on the Mac, this works fine on the PC.

I was just wondering if anyone found a solution to the synchronisation problem, is there a way to create a JavaScript buffer or a way of synchronising the messages?

Best Regards,
Malcolm Murray

Please take a look at this topic which includes the following:

@unknownuser said:

Also included is revisions to code to enable testing Mac compatibility, viz:

START control employed as no Sketchup.active_model with Mac when Ruby scripts are first loaded. (related post)

Code rewritten so that no window.location call is followed by any javascript statements. (related post)

Feedback from Mac users and/or coders would be much appreciated.

together with a download of an example.

I think it very important for the expansion of webdialog use to find and publish the best common solution. I don't expect the SU team has this at the top of their list.

I look forward to further discussion.

My regards

Chris

thomthom

@chrisglasier said:

As a result, if on Mac you call in sequence 2 javascripts:

Code: Select all
dlg.execute_script "document.getElementById('Field1').value = '1' ; "
dlg.execute_script "document.getElementById('Field2').value = '2' ; "

then,

the first Ruby statement returns even before its javascript function starts executing

Most likely, only the second javascript function will be executed, because it will override the first one.

On Windows, it works fine. Each 'execute_script' Ruby statement will only return when the javascript function has finished execution.

I've been doing some tests on OSX, using the console. First I create a new WebDialog object:


w=UI;;WebDialog.new('test', true)
w.set_html('<html><body>Hello</body><html>')
w.show

Then I try with a loop to send lots of .execute_script commands.


w.execute_script('document.body.innerHTML="";')
(0..100).each{|i| w.execute_script('document.body.innerHTML="<br>Hello #{i}";') }

When I run the script, it adds all the lines "Hello 1" to "Hello 100" - not a single .execute_script is lost...
Also, the ruby method did not return until it was all done.

thomthom

Testing the other way - making a loop in the Javascript to do 100 window.location = 'skp:callback' and I only register the last callback. All the rest appear to have been suppressed. I only see the async going from the WebDialog to Ruby. Not the other way around.

thomthom

Here's a sample code I used to test:

webdialog.rb

thomthom

I improved the test. Now the Ruby to WebDialog method creates a new DIV element every time, and it insert the DIV into the last inserted DIV. So if the calls are synchronous - all the elements should be nested.

On both PC and OSX - the elements are nested. It still appears to me that it's just the Webdialog to Ruby path that's async. Which means it's related to window.location.

webdialog.zip

jeff hammond

i have no idea what you're actually talking about thomas but i'm glad you are
i fear the day of a great plugin coming out only to hear this once again : "sorry, pc only"

chrisglasier

@thomthom said:

window.location

Yes that's the culprit as I understand what Fredo said and you have demonstrated (to yourself).

thomthom

@chrisglasier said:

@thomthom said:

window.location

Yes that's the culprit as I understand what Fredo said and you have demonstrated (to yourself).

No, he also described .execute_script to be async - which I can't see. From my tests it returns after the Javascript is done, not before.

fredo6

@thomthom said:

@chrisglasier said:

@thomthom said:

window.location

Yes that's the culprit as I understand what Fredo said and you have demonstrated (to yourself).

No, he also described .execute_script to be async - which I can't see. From my tests it returns after the Javascript is done, not before.

Tom,

There are 2 issues which all boil down to the problem of windows.location being asynchronous.

when you execute a script that should call a Ruby call back, the script returns before the call back is executed. This is unfortunately a design problem due to Safari, which I understand the SU team cannot do anything about easily.
in addition, the skp protocol eats up all callbacks and keep the last one, when sent in sequence. So you simply miss some callbacks, even if they were to be recieved asynchronously. This is a problem of implementation by the SU team (it would have deserved a buffering).

I had to find workarounds for both problems in my web dialog implementation in LibFredo6, precisely by buffering the callbacks in a hidden HTML field and synchronizing the Ruby code.

If I have some time, I will check if I could isolate the code for reuse by others. No promise however.

Fredo

thomthom

@unknownuser said:

when you execute a script that should call a Ruby call back, the script returns before the call back is executed. This is unfortunately a design problem due to Safari, which I understand the SU team cannot do anything about easily.

Ah, ok. So the .execute_script is synchronous then. It's just the Javascript to Ruby callback (the skp: protocol) that's async.

So it's then safe to call .execute_script which calls a javascript method that stores the return data in a hidden input field where you then use .get_element_value to return data, correct? This is what I see from my testing - but I just want to make sure I'm not missing some cases here.

fredo6

@thomthom said:

So it's then safe to call .execute_script which calls a javascript method that stores the return data in a hidden input field where you then use .get_element_value to return data, correct? This is what I see from my testing - but I just want to make sure I'm not missing some cases here.

Correct. This is what should be done to solve problem #1.
Can you confirm however, because it's been a while since I did not work on Web dialogs, and I don't want to mislead anybody.

Fredo

thomthom

I've tried with loops of .execute_string followed immediately by .get_element_value where I call a Javascript function to modify an argument I pass to it and fetch the result with .get_element_value. Works fine on PC and OSX.


// #bar is a hidden INPUT element
function foo(i)
{
  document.getElementById('bar').valie = i * i;
}


(2..10).each { |i|
  dialog.execute_script("foo(#{i});")
  x = dialog.get_element_value('bar')0
  puts "i; #{i} - x; #{x}"
}

This seems to work fine.

RonB

Sorry for exhuming this thread, but is there a workaround available now?
Actually i'm facing the same problem as described here and its totally driving me nuts.

I'm hoping for good news.

thomthom

Depends on what you are doing.

One way is to make SketchUp pump for information instead of Javascript pushing information.

Another way, if you need Javascript to push information is to set up a pump-system. You create a stack (an array) of the callbacks from JS to SU you want to perform. A function then takes the first item on the stack and send it to SketchUp. It then waits for SketchUp to send notification back that the message was received. Then the next item on the stack is sent ... and so on.

It requires you to restructure how you pass the information around.

If you give a specific usage example we could probably come up with suitable design.

RonB

hey thomthom, thanks for your quick response.

I do have a website providing two informations for sketchup

the actual needed version of the plugin (provided by hidden input field)
a stream (string) of informations (provided by hidden input field)
needs to be checked directly when the webdialog loads the site and 2) when a button is clicked (because it can be chosen which set of informations to load).

Actually it is working on a PC but not on a Mac.
The Website contains both window.location skp callbacks but the second one is only triggered by button.

thomthom

That sounds like you are sending back before the HTML DOM is ready. If you use jQuery use the 'ready' event to wait for the HTML DOM to be ready.

How have you currently structured the loading event?

RonB

I guess you're right... i do have the skp callback somewhere in between of the page.
I'll try to change it to jquery with the "wait for doc ready"-function and report back here.

to answer your question: I'm creating a webdialog and connect by set_url to an url.
Then i'm showing the dialog and wait for the callbacks.
I hope that's what you was asking.