SketchUp and OSX Mavericks....
-
Actually, it does just seem to be exactly that, allow_actions_from_host.
I had noticed with V6 that it was ignored, so I never implemented it.
But in my remote WebDialog, which is failing, I simply add an allow_actions_from_host, and suddenly now it's working again.--J
-
I'll jump in now, I concur that it all appears to be related to the dlg.allow_actions_from_host method. I think its possible that Win and OS have not actually been honoring that method. But Mavericks now suddenly does.
So if people are not using it, it will dis-allow certain actions with remote websites and throw that error.
If you do use it (which you really should now), make sure you have the syntax correct. You should be giving it a domain, not a url. example:
dlg.allow_actions_from_host("http://www.sketchup.com")is not correct, it should bedlg.allow_actions_from_host"www.sketchup.com"Now I'm curious to know if that is enough to fix all/any of the problems, or are people still seeing other problems?
Chris
-
@tig said:
Correcting the typo in the remote version does not change things anyway - the remote still fails with Mavericks... but the local version succeeds [with the unnecessary 'allow' method removed, on with the typo corrected or the typo intact]
BUT the weird thing is that if you try the [corrected OR typo-ed] tests on a pre-Maverick MAC or a PC, then both the local and remote versions perform just fine, as if the 'allow' and/or typo is ignored and the 'allow' is 'an irrelevance'
OK, this just keeps getting weirder
On my Mavericks Mac, TIG.remote works just fine after the typo is corrected. What the bleep is going on???? -
@slbaumgartner said:
OK, this just keeps getting weirder
On my Mavericks Mac, TIG.remote works just fine after the typo is corrected. What the bleep is going on????That is what we're seeing here as well Steve. From what we're seeing this all boils down to either having not included the allow_actions_from_host either not being implemented at all, or having been implemented with bad syntax (a url vs a domain string), or a typo.
It appears no other OS, other than Mavericks, actually pays any attention to this method. That is what my quick testing is showing. I'm very open to hear about exceptions to these findings or issues that might be different.
Chris
-
@chris fullmer said:
@slbaumgartner said:
OK, this just keeps getting weirder
On my Mavericks Mac, TIG.remote works just fine after the typo is corrected. What the bleep is going on????That is what we're seeing here as well Steve. From what we're seeing this all boils down to either having not included the allow_actions_from_host either not being implemented at all, or having been implemented with bad syntax (a url vs a domain string), or a typo.
It appears no other OS, other than Mavericks, actually pays any attention to this method. That is what my quick testing is showing. I'm very open to hear about exceptions to these findings or issues that might be different.
Chris
Whew, at least I might not be losing my mind
I read the documentation for this method multiple of times and I am not at all sure I understand it
What sort of "actions" could take place on a "host remote from the host where the WebDialog exists"? That seems to say that an action callback could be routed to a remote host? How? The skp: protocol handler is part of the WebDialog code running on the local host...very confused... -
After playing around with this a bit more, I may have answered my own question. On my Mavericks Mac, the skp:callback from TIG.remote fails with the now familiar error message if the call to allow_actions_from_host is omitted or invoked with a bad argument when the WebDialog is set up by Ruby (which is what Chris said before, I just didn't understand).
So, the concern isn't about executing an action on a remote host, it is about preventing skp: callbacks when the WebDialog contents were loaded from a remote host and might be malicious. Restricting the callbacks to pages from only trusted domains registered with this method then makes sense.
Which, of course, doesn't answer the question of why this method is ignored on most OS's and suddenly started working in Mavericks! But that will have to be answered by the Trimble SketchUp engineers, since the rest of us have no insight as to how this part of WebDialog is implemented.
As a note to the Trimble engineers: it would have been a lot easier for us outsiders to track this down if the error message was clearer. The message reports the full URL of the callback that it doesn't like (which is why we see the skp:callback@ part), and calls it an "Invalid URL" whereas it is actually a prohibited callback from a page that wasn't vetted by the Ruby code.
-
So to recap...
If a webdialog uses a remote url and it uses
allow_actions_from_host(string)and that 'string' is somehow incorrectly formed, then it is ignored by all OSs which continue to operate correctly with its callbacks - except for Mavericks which always fails !
But with a correctly formed 'string' that is a 'domain' Maverick succeeds too.
Mavericks will fail if the dialog is using a remote url BUT it does not include aallow_actions_from_host(string), or of course if it is used and the 'string' is not a proper 'domain'.In the case of SketchThis's dialog that host 'string' [given by the web-developer] included an initial
http://- making it a 'url' rather than a 'domain', with all OSs it had previously worked OK anyway, but now it failed when used with the new Mavericks...
This 'string' has now been corrected in the SketchThis code, it is now a 'domain' without an initialhttp://, and it now works correctly with the SketchThis dialog callbacks.In contrast with the SketchUcation's Plugin Store dialog that 'string' was already correctly formed as a 'domain', and therefore it worked on ALL OSs, including Mavericks.
So anyone experiencing issues like this with remote url dialogs Mavericks-only should check that their dialog includes the
allow_actions_from_host(string)AND that it has a good 'string' that is a 'domain' and not a 'url' [or a typo!]...
This good-practice will also future-proof their code against any IE updates that might replicate the somewhat excessive care that is now taken by Maverick's version of Safari... -
I have experienced a few bugs. I'm not entirely if they are related to Mavericks, but they seem to have appeared after the update.
- My tool palettes ( Layers, Style, Scenes, etc ) don't "stick" together anymore. When I click on them to enlarge, they just dissociate from the others, which is pretty annoying.
- I have experienced a few other visual bugs while using Mission Control (with the gestures) ; palettes don't come back as they should, or just slower performances.
-
@tig said:
So to recap...
...
So anyone experiencing issues like this with remote url dialogs Mavericks-only should check that their dialog includes theallow_actions_from_host(string)AND that it has a good 'string' that is a 'domain' and not a 'url' [or a typo!]... ...Hum... will this also correct the "Java Script disabled" problem ?
-
@mariocha said:
Hum... will this also correct the "Java Script disabled" problem ?
Hi Mariocha,
I think it will. Keyframe Animation reports that error when it can't connect to the server. The web dialog that would connect is probably failing because I didn't implement the
WebDialog.allow_actions_from_hostmethod. I'll release an update as soon as I have a chance. Perhaps you could test it for me -- I don't have a computer with Mavericks. -
Make sure you pass the method a valid domain-name - NOT the http:// address...
That 'type' error and also typos in a seeming correct domain-name etc caused difficult to track-down issues [with Mavericks only] when included in some other scripts that use that method -
hi, i tried to import a .dwg file to sketch up and this warning appears instantly: "warning, importer not found".
thanks.
I'm running sketch up pro 8 on Mac osx 10.9, and the .dwg file is 2010. -
In my case (SU 8 PRO& Mavericks) I can't import DWG files. A dialog appears saying: Alert, importer not found. Also I noticed that the Palettes don't work as expected. Very sad don't know what to do ?
-
@unknownuser said:
.... Perhaps you could test it for me -- I don't have a computer with Mavericks.
I will sure be glad to give it a try, Doug.
Your plugin is a must for me.
updt: Received a beta, works just fine.
updt: New version 1.8.4 available on the Regular Polygon website. -
Just for info.
Here there is no problem importing dwg files, on both my computers under Maverick. -
@didierml said:
I have experienced a few bugs. I'm not entirely if they are related to Mavericks, but they seem to have appeared after the update.
- My tool palettes ( Layers, Style, Scenes, etc ) don't "stick" together anymore. When I click on them to enlarge, they just dissociate from the others, which is pretty annoying. ...
It is indeed pretty annoying. It was a very appreciated feature. Hoping a maintenance update will correct that ! Please ?
updt: My wish for the new year ! -
@martychristoffel said:
I'm running into palettes that are no longer "sticky" since upgrading to Mavericks. To be more precise, although the palettes do snap to one another, when expanding one such as the Layers palette, it opens underneath the minimized Styles, Scenes, etc. instead of having those palettes remain connected to the Layers pane. When minimizing them down to their title bars, they can also lose their relative association to other palettes.
ME Too!
-
2014 Sticky palettes are back !!!
Now how about bringing back thumbnail icon of SkUp files in Finder. Was there up to v8. So practical.
Anyway very happy with v2014. Full congrats to the SU team !
Advertisement