Between different Macs plugin works and doesn't work
-
So I have been helping Garry K with his curved staircase plugin on Mac http://sketchucation.com/forums/viewtopic.php?f=183%26amp;t=54157%26amp;p=510842#p510842 this is the 6th page in the thread and the plugin won't work on my Mac Pro with Lion and SU8 everything is up to date Safari Version 6.1.1 (7537.73.11) and I have emptied caches but it works fine on MBP with Mavericks and latest Safari build. Any ideas anyone.
Thanks Walt
-
that's the same thing i'm getting with that plugin.
http://sketchucation.com/forums/viewtopic.php?p=510390#p510390
works on my laptop with mavericks.. doesn't connect on my desktop with lion.
-
peculiar
-
Peculiar indeed! I have only a Mavericks box, so I can't test this. Have you checked the Console log for errors? Seems ironic, as most of the complaints these days are about things not working in Mavericks that were fine in 10.8.
Ultimately, we will have to rely on Gary K to debug this. His source code is scrambled and only he knows quite what it does.
-
Maybe another plugin causing the problem?
-
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 -
@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
PascalWhat 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.
-
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.
-
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...
-
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.
-
@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
-
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
-
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?
-
@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
-
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
-
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... -
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)
-
-
This is what I get Garry
-
Just to be sure - you downloaded the latest dialog_test.rb and line 10 now says:
@dlg.allow_actions_from_host( 'cabmaker32.com/' );
Advertisement