Working around "location=", for debugging

[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