Between different Macs plugin works and doesn't work

[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:

https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS

[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

[mwm5053]

@ Steve When I right click in Connect to Website all I get is "Reload" but this is what Terminal looks like after pressing return in terminal was that right?

---

[slbaumgartner]

@mwm5053 said:

@ Steve When I right click in Connect to Website all I get is "Reload" but this is what Terminal looks like after pressing return in terminal was that right?

The Terminal screenshot looks as if you left off part of the command. Did you type the entire line

defaults write com.google.sketchuppro8 WebKitDeveloperExtras -bool true

I forgot to mention that before entering this command you should quit SketchUp and restart it afterward. Until the default takes hold the right-click menu will only contain "Reload".

Steve

[mwm5053]

I double checked the terminal and retyped and restated SU still no right click web inspector?

---

[slbaumgartner]

@mwm5053 said:

I double checked the terminal and retyped and restated SU still no right click web inspector?

Missed it again! You typed com.google.sketchup8pro, it should be com.google.sketchuppro8

Steve

[mwm5053]