Working around "location=", for debugging

RichMorin

Because I'm using WebDialog with temporary files (eg, *.{css,html,js), I can point a normal browser (eg, Safari, Firefox) at them and get useful debugging help. Unfortunately, these browsers get terribly confused if my code uses the "location='skp:...'" hack.

I'd like to find a run-time way to get around this problem. If I could tell that I was running under a normal browser, I could avoid running the "location='skp:...'" command. Alternatively, maybe there's a way to intercept the event (or ???) that the command causes. I'm not particular (:-).

I tried dumping the contents of the navigator object in an alert, under both SketchUp and Safari, but the results are the same, so no luck there. I also tried writing a JS function that would ignore the exception:


safe_loc = function(string) {
  try       { location = string; }
  catch (e) { }  // Ignore errors.
}

Can someone suggest a way to handle this?

thomthom

http://code.google.com/apis/sketchup/docs/releases.html

@unknownuser said:

WebDialog User Agent Updated
It used to be that WebDialogs would send a useragent string unique to SketchUp. We now send a useragent that is a concatenation with the embedded browser's original useragent and an extra string to identity SketchUp. This allows the Google Earth plugin (and similar plugins) to correctly detect the kind of browser so it works properly inside SketchUp.

RichMorin

I figured out a way around the problem. I define an empty safe_loc function in my JS file, giving the browsers something safe to call. I then redefine it to (after the dialog is launched) from the plugin, making it work under SketchUp.

thomthom

checking the user agent string should let you automate it.

RichMorin

No, the user agent strings are identical between the SU WebDialog and Safari.

RichMorin

My "way around the problem", described above, didn't quite work. Problem is, there's no reliable way to send code to the dialog until it has indicated (eg, via location=...) that it's alive. And, of course, the location=... code is what I'm trying to add.

My current hack, which seems to be working (if ugly), is to write two copies of the HTML file (eg, main.html and DBG_main.html). If I use the latter in the browser, I can test for it, as:


function set_loc(string) {
  var patt = /DBG_/;
  var url  = document.documentURI;
  if (!patt.test(url)) { location = string; }
}

thomthom

How about sending a message to the webdialog once it's loaded and set a flag to indicate webdialog or not?

RichMorin

As I understand it, there's no reliable way for the plugin code to know when the webdialog has been loaded, except to wait for a "location=..." message. And, if I try to send that message in the browser environment, I crash. So, I seem to have a "chicken and egg" problem. Am I missing something?

Jim

Can't speak about the Mac, but I was able to register the skp: protocol in Firefox on Windows.

thomthom

@richmorin said:

As I understand it, there's no reliable way for the plugin code to know when the webdialog has been loaded, except to wait for a "location=..." message. And, if I try to send that message in the browser environment, I crash. So, I seem to have a "chicken and egg" problem. Am I missing something?


wd.show {
  wd.execute_script('is_webdialog = true;')
}

?

AdamB

FWIW On Mac, the string from a WebDialog is:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-us) AppleWebKit/533.18.1 (KHTML, like Gecko)

but from Safari its:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-us) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5

So you could detect this.

Sure this is been discussed before, but isn't the simplest thing to install a scheme handler that does nothing?

RichMorin

Good catch! I had looked at the appVersion strings, but failed to notice the extra goo at the end of the Safari version.

I'm not sure what you mean by "isn't the simplest thing to install a scheme handler that does nothing". Could you please give more details?

RichMorin

Here is the comment block I put in my code. I think it summarizes what I know about this issue. Comments welcome...


# It's a bit tricky to determine whether this
# method is running under SU or a web browser.
# The first way I found, which is solid but
# clunky, is to write a second copy of the HTML
# file using a name such as DBG_main.html,
# allowing this test to work;
#
#   document.documentURI.match(/DBG_/) ||
#     (location = string);
#
# Adam Billyard (AdamB on SketchUcation) pointed
# out that Safari puts some extra goo at the end
# of the appVersion string.  So, here's a less
# clunky (but possibly brittle) alternative;
#
#   navigator.appVersion.match(/533\.18\.5$/) ||
#     (location = string);
#
# Thomas Thomassen (thomthom on SketchUcation),
# pointed out that JavaScript code may be reliably
# sent from a block attached to the show() or
# show_modal() call, as;
#
#   wd.show_modal do
#     wd.execute_script('env_is_webdialog = true;')
#   end
#
# This allows the technique below to be used;
#
#   env_is_webdialog && (location = string);

Dan Rathbun

I was under the impression that the code block of show() and show_modal() did not work on the Mac.
Has this been fixed on SU 8.x ??

thomthom

hmm.... you might be right about that... when you mention it I do imagine there was some issues...

RichMorin

@dan rathbun said:

I was under the impression that the code block of show() and show_modal() did not work on the Mac.
Has this been fixed on SU 8.x ??

Dunno, in general, but a quick experiment worked for me. Then again, I was only setting a single variable.

-r

Working around &quot;location=&quot;, for debugging

Working around "location=", for debugging