Between different Macs plugin works and doesn't work

[slbaumgartner]

@ppoublan said:

Dear all,
maybe nothing to do with this issue, but just fixed a bug with plugin and Mac and did not find the reason, just a workaround I want to share :
multiple calls to window.location worked fine on PC, but on Mac only the last call to window .location were received by SU from the webdialog.
Replaced all the window.location from Javascript by SU calling webdialog.get_element_value and this worked.
Yours
Pascal

What you describe is a consequence of the well-known way that javascript calls to Ruby are asynchronous on the Mac. We discussed this in the thread with Garry K, and he is aware of the possibility. But the topic here is a different mystery: Garry's plugin makes connections to his site over the internet, and on some Macs these connections fail while on others they work fine. The failures seem somehow connected with Mountain Lion.

[Garry K]

I did post a very small app ( not scrambled ) that was able to produce the error. It is dialog_test.rb

http://sketchucation.com/forums/viewtopic.php?f=183%26amp;t=54157%26amp;p=510850#p510850

I believe that Walt was able to duplicate the issue with his desktop.

There is a single web dialog and 1 http call.
The web dialog does call the ruby script twice. Once when the DOM is loaded and once with the results of the http call.

The other direction there was but 1 call.

[slbaumgartner]

Looking at the test app, it does seem to me that on Mac the async javascript could run ahead and complete the xmlHttp request before Ruby has returned from the initial callback. That is, the js function from_ruby kicks off the request and sets another js function to track progress, which on Mac can proceed without waiting for Ruby.

But that doesn't explain the status=0 error message or the different behavior between Mavericks and Mountain Lion...

[mwm5053]

I can't help you guys much sorry not a code man, but just some input if I may, the problem slbaumgartner is Lion 1.7.5 for me not MT Lion maybe it has a problem too. If Java is the culprit I have it enabled in Safari prefs but globally disabled in System Pref if that helps any.

[slbaumgartner]

@mwm5053 said:

I can't help you guys much sorry not a code man, but just some input if I may, the problem slbaumgartner is Lion 1.7.5 for me not MT Lion maybe it has a problem too. If Java is the culprit I have it enabled in Safari prefs but globally disabled in System Pref if that helps any.

Sorry, I didn't read back carefully to see exactly which versions of Mac OS were giving the problems.

But Javascript is completely unrelated to Java other than via an unfortunate choice of name. Your java settings have no effect on this.

Steve

[slbaumgartner]

The reduced javascript code sends 'http error ' + xmlHttp.status back to Ruby and Ruby displays it in a UI.messagebox. The screenshots Walt posted on the other topic show that this callback arrived at Ruby correctly, so the problem is not with asynchronous javascript vs Ruby.

Most of the incidents of status 0 reported on the web attribute it to cross-domain requests. That is, for security reasons XMLHttpRequest does not allow requests to be sent to a domain other than the original one. I wonder if there is a bug (or maybe a "feature") in WebKit on Lion that made it less tolerant of this, for example, concluding that since the html and its scripts were loaded locally only the localhost should be allowed? I confess that even after reading a lot about this I don't quite understand it...

Garry, have you tried catching the onerror event? I wonder if it would tell you what is wrong when things fail on Walt's Mac..

Steve

[Garry K]

I'm not sure that there is an http error. A value of 0 suggests that the call did not go beyond the computer. This suggests that it is possible that it has something to do with cross-domain requests. However, Sketchup does have the allow_actions_from_host which was set. I thought allow_actions_from_host was specifically for that, in otherwords to reduce security risks by allowing 1 and 1 only external call.

What we could do is rem out the "loaded" part where we add the listener for DOMContentLoaded and replace that with a button and push the data to a hidden field.

Then there is but one call back going in one direction. Now if that doesn't work then we have ruled out this being an asynchronous timing thing.

Any thoughts?

[slbaumgartner]

@garry k said:

I'm not sure that there is an http error. A value of 0 suggests that the call did not go beyond the computer. This suggests that it is possible that it has something to do with cross-domain requests. However, Sketchup does have the allow_actions_from_host which was set. I thought allow_actions_from_host was specifically for that, in otherwords to reduce security risks by allowing 1 and 1 only external call.

What we could do is rem out the "loaded" part where we add the listener for DOMContentLoaded and replace that with a button and push the data to a hidden field.

Then there is but one call back going in one direction. Now if that doesn't work then we have ruled out this being an asynchronous timing thing.

Any thoughts?

Rambling thoughts...

I've become convinced that it is not an async timing problem. I also don't think it is an http error per-se, since those report three-digit codes (your javascript labels it an "http error", not the system). I suspect the request is being killed within the javascript library without ever going to the server. Have you checked the server logs to see whether they get traffic when Walt's system logs the error? My guess is no.

I didn't find any discussion about ways for client-side code to turn off the blocking of cross-domain requests,
only server-side headers that could be returned. It seems unlikely that there is a way for client code to disable the action, since that would make it essentially useless! What good is having a lock on the door if you provide a turn button to disengage it? So, I'd be surprised if SU's allow_actions_from_host defeats this particular security feature (or if it does, I'd like to know how - this is another of the poorly explained features of the API).

From what I read, at least on many web libraries, XMLHttpRequest has an onerror event handler you can set that may provide a description of what went wrong. Something like

xmlHttpRequest.onerror = function(e) {alert("request error; " + e.status.text)};

It may be that the error message also shows up on a javascript console, if people with the problem can get one open before running the plugin.

Steve

[slbaumgartner]

More thoughts: I don't think it is allow_actions_from_host. From what I looked up, that setting controls whether skp: callbacks are allowed from WebDialog contents loaded from a remote host. It is a sort of whitelist that gates whether skp: will work (and actually did nothing on OS X prior to Mavericks!). But clearly you are getting callbacks from javascript to Ruby ok. I still think it is most likely a change in handling of the AJAX cross-domain security in Lion vs later OS X. And I have no clue how to work around it

[TIG]

If a webdialog is not connecting to a server across the Internet you should never need to specify dlg.allow_actions_from_host(host) at all...
If you do need to use it, then make sure that its argument is a 'domain' - like 'sketchucation.com' - and not an 'http-address' - like 'http://sketchucation.com'.
On PCs and non-Mavericks MACs this difference was not a critical matter, but mis-setting it will surely break your webdialogs under the stricter Safari shipped with the new Mavericks.
So it's best to ensure that a valid 'domain' is used...

[slbaumgartner]

Garry,

You might want to try out some of the CORS methods described in this article:

Cross-Origin Resource Sharing (CORS) - HTTP | MDN

Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. CORS also relies on a mechanism by which browsers make a "preflight" request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.

MDN Web Docs (developer.mozilla.org)

[Garry K]

Jeff and Walt

I changed this based on what TIG said.

Please try it

---

modified dialog_test.rb

[mwm5053]

This is what I get Garry

---

[Garry K]

Just to be sure - you downloaded the latest dialog_test.rb and line 10 now says:
@dlg.allow_actions_from_host( 'cabmaker32.com/' );

[mwm5053]

Yes Garry I deleted the other one and installed the the new one.

---

[slbaumgartner]

@garry k said:

Just to be sure - you downloaded the latest dialog_test.rb and line 10 now says:
@dlg.allow_actions_from_host( 'cabmaker32.com/' );

Trailing slash not needed. Just 'cabmaker32.com'

[TIG]

Remove the final / in the domain name.

[Garry K]

Jeff and Walt

I have now removed the trailing slash from cabmaker32.com on line 10

Maybe this will work.
Please try it

---

cleaned up the domain address

[mwm5053]

Got the same error, sorry wish I could be of more help

[slbaumgartner]

@mwm5053 said:

Got the same error, sorry wish I could be of more help

Walt,

Do you have the WebKit inspector activated? If not, please open a Terminal window and type

defaults write <bundleid> WebKitDeveloperExtras -bool true

where you replace <bundleid> with:
com.google.sketchupfree8 for v8 Free
com.google.sketchuppro8 for v8 Pro (what your info says you have)
com.sketchup.SketchUp for 2013

After doing that, please run Garry's test script and while the WebDialog labeled "connect to website" is still open, right-click on it and select "Inspect Element" from the popup menu. This will open the WebKit Inspector. The GUI of the WebKit Inspector has changed with version, but look for something labeled "Console" and click it. Please let us know if the Console displays any error or warning messages.

Thanks
Steve