SketchUp and OSX Mavericks....

driven

... cannot run saying Java Script needs to be enabled, but it is.

Being enabled in Safari, will not effect WebDialogs, which have JS enabled by default...
you can check what works in SU with something like this pasted into Ruby Console

 wwhdlg = UI;;WebDialog.new("wot_works_here", true, "wwh", 739, 641, 50, 50, true);
 wwhdlg.set_url "http://dante.dojotoolkit.org/hasjs/tests/runTests.html"
 wwhdlg.show_modal

john

TIG

@chris fullmer said:

RE: the test file used here - we found that the test file has a typo in it, and that is why the remote download is failing in that script. It actually is trying to reach an invalid URL

So unfortunately that isn't showing any errors once the typo is corrected.

We're still looking into this.
@Chris
Do you refer to Eric's post that modified some test rb/html I set up - using href=... ?
I find that it works fine in both .local and .remote versions on all OSs... except with MAC-Mavericks with just .remote...
If you explain the typo we could look at it [help us to help you...] BUT... it only fails for me on MAC-Mavericks using a .remote html - so IF it has a typo why would it work OK in the other OSs ???

driven

works on mavericks with 'dropboxusercontent vs. dropboxusercontext'
john

TIG

Yes I now have the typo - passed from another source...

That must be Eric’s Web-guy’s typo... he added that 'remote' code to an earlier test setup I wrote... however, it still works fine on all OSs [except Mavericks] with AND without that typo ???

I confirm that the corrected 'allow_actions_from_host' code does now work on Mavericks as well as all other OSs... most puzzling...

BUT this begs the questions... as to why very similar code fails in the SketchThis toolset, when its 'allow_actions_from_host' IS identical to the url that its ruby specifies...
???

Chris Fullmer

Thanks John - I think that is the typo in question.

As to why it works in all other OS's except for Mavericks.....that I don't know.

Chris Fullmer

Oh, TIG already responded. Yes, this is an odd one.

Warped9

I started this discussion so I might as well put in my two cents. My experience with Mavericks so far has been generally positive. In regard to SketchUp I installed Make while keeping SU8 on hand for now. SU8 doesn't seem to run any different for me (as far as I can tell) on Mavericks than it did with Mountain Lion. However, Make does seem to run somewhat better (as far as I can tell) with Mavericks than SU8 does with Mountain Lion.

One odd thing, though. My SketchUcation Store plugin doesn't connect anymore in SU8. I just get a message saying V2 is available, but when I try to click for the update I just get an error message. I can still install extensions the old way by downloading them manually and using the Extensions Manager found in SU Preferences. I've even tried installing the V2 of SketchUcation Store through the Extensions Manager and I still get the error message afterwards when I try to use the plugin. The SketchUcation Store plugin works fine in Make.

slbaumgartner

@chris fullmer said:

Oh, TIG already responded. Yes, this is an odd one.

Chris,

It is easy to scan the WebDialog framework and confirm that this error message emerges from it, not from a Mavericks system library or framework. But without reverse engineering the WebDialog code (which for ethical reasons I won't attempt), it is impossible for us outsiders to know what WebDialog is trying to do when it throws this error. I have built and think that I understand the sample custom protocol handler that Apple provides, but it does not trap any issues with the URL. Without disclosing some proprietary info, would it be possible for the Trimble engineers to tell us what logic test fails when WebDialog throws this error? That info would help to track down what about Mavericks and certain URLs is peculiar to the problem.

As a different matter, it seems like this topic has gotten quite technical - maybe it should be moved or restarted in the Developers forum?

Thanks
Steve

Chris Fullmer

Yeah, the developer's forum is a good place for it I think.

Still looking into it on our end, nothing new to add to the discussion yet.

Chris

TIG

It's already in the Devs' forum

Chris Fullmer

I just had my mind blown

slbaumgartner

For what it's worth, I just noticed that the same typo was present in both the TIG.remote and TIG.local methods, but only the TIG.remote failed due to the typo. Does allow_actions_from_host() look at previously loaded pages to see whether that host is used by any of them? How does the SketchThis ruby obtain the host URL it passes to this method?

slbaumgartner

@tig said:

It's already in the Devs' forum

faster than a speeding bullet...

TIG

And of course the local version didn't need the' allow' anyway - it was a web-guy/Eric tinkering with my original ruby
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'

honkinberry

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

Chris Fullmer

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 be dlg.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

slbaumgartner

@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????

Chris Fullmer

@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

slbaumgartner

@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...

slbaumgartner

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.