WebDialog.set_html fails under Safari 5.0.6

NeilBlanchard

*%(#0080BF)[This thread was extracted from the CleanUp thread. I separated it in order to make it easier to follow the discussion for this issue.

The issue was initially reported here: http://forums.sketchucation.com/viewtopic.php?f=323&t=22920&start=360#p346134

In short summary, when you use .set_html with Safari 5.0.6 local resources, iamges, JS, CSS etc doesn't load. Appear to be new security restrictions.

Related post: http://forums.sketchucation.com/viewtopic.php?f=180&t=34714

Workaround Code Snippet
http://forums.sketchucation.com/viewtopic.php?f=180&t=39842&p=352375#p352375

-ThomThom]*

I'm seeing this exact same thing. I'm using Snow Leopard and Pro v8.0.4810. I close the tool palette and the gray screen goes away.

@wrc86 said:

it's not working for me, it doesn't show any error when I start SU
It just to work with my old OS, now I'm working with OS X LION

I would dearly love this to work -- I am trying to build an electric car, and I'm using a PhlatboyZ PhlatPrinter III, which generates the g-code from SketchUp faces. Here's the imported DWG that clearly has pretty crisp edges, but has no faces at all:

I've got about 50 more of these to work through, so if I can use this script to get faces easily, I would be eternally grateful!

Edit: I got the faces to work -- most worked by adding one line, and a couple required closing some tiny (> 1/32") gaps. I then was able to use the Phlatboyz Tools (plugin for SU) to generate the outside and inside cutting paths, in preparation for making the g-code. Here's the nearly completed first layout sheet:

Thanks for your excellent plugin -- it has helped a lot.

Sincerely, Neil

driven

@neilblanchard said:

I'm seeing this exact same thing. I'm using Snow Leopard and Pro v8.0.4810. I close the tool palette and the gray screen goes away.
I've got about 50 more of these to work through, so if I can use this script to get faces easily, I would be eternally grateful!

Sincerely, Neil

I was writing when you updated, but here it is anyway...
@ Neil, mine does that as well, but if you use the second context menu item 'Clean with last settings' it does actually work. So if you had it set up before the problem it should run...

@thomas, this is definitely the Safari 5.0.6 and Safari 5.1 security issue with the file load paths. it's also affecting Fredo's 'images' loading and his updater.

however, because you both use convoluted (ruby/js) html creation I can't work out how to specify a simple path.

I'll do some more investigations...
john

thomthom

@driven said:

however, because you both use convoluted (ruby/js) html creation I can't work out how to specify a simple path.

Because it's not a simple path... it's created dynamically. I'll try to get to the bottom of it.

thomthom

@driven said:

I'm still on 10.5.8, but safari 5.0.6 is the pre-release for the next safari and it stops Fredo's updater from checking here for updates, but I haven't had any local file errors from anything else, and sellectionToys works...

[attachment=2:a5f6zxlv]OSX 10.5.8 + Safari 5.0.png[/attachment:a5f6zxlv]

Any chance you can test something for me:
[attachment=0:a5f6zxlv]window.zip[/attachment:a5f6zxlv]

Replace the old window.html file, and have a look at the error console (in your screenshot) again.
It won't fix all loading errors, but it will give me a clue if it reduces some of the errors.

Extract into TT_Lib2/webdialog/

driven

thomthom

Cursed!

Just to verify, can you send me the source code of the dialog that opens? (Right click > View Source) ?

driven

it's quite small, so here it is...

BTW. you can't view source in SU but you can right click on the html tag in Web Inspector and copy as html (the whole file)

<html xmlns="http://www.w3.org/1999/xhtml" xml;lang="en-gb" lang="en-gb"><head>
	<meta http-equiv="X-UA-Compatible" content="IE=8">
	<meta http-equiv="content-type" content="text/html; charset=utf-8">
	<meta http-equiv="MSThemeCompatible" content="Yes">
	<!--<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />-->
	<!--<meta http-equiv="X-UA-Compatible" content="IE=8"/>-->
	
	<base href="file;///Library/Application Support/Google SketchUp 8/SketchUp/Plugins/TT_Lib2/webdialog/">
	<link rel="stylesheet" type="text/css" media="screen" href="css/ui.css">
	<link rel="stylesheet" type="text/css" media="screen" href="file;///Library/Application Support/Google SketchUp 8/SketchUp/Plugins/TT_Lib2/webdialog/css/inputbox.css">
	<style type="text/css">html{overflow;hidden;}</style>
	<title>%TITLE%</title>
	<script type="text/javascript" src="js/jquery.js"></script>
	<script type="text/javascript" src="js/base.js"></script>
	<script type="text/javascript" src="file;///Library/Application Support/Google SketchUp 8/SketchUp/Plugins/TT_Lib2/webdialog/js/inputbox.js"></script>
	
	<!--
	<script type="text/javascript" src="https://getfirebug.com/firebug-lite.js"></script>
	-->
</head>
<body>



<!-- <a href="#">file;///Library/Application Support/Google SketchUp 8/SketchUp/Plugins/TT_Lib2/webdialog/</a> -->


</body></html>

thomthom

hmm... Right. This looks like a nasty debug session coming up.

I wonder why on earth Safari would prevent loading of resources from file:// ...
Is it the file:/// protocol? Surely this would block viewing local webpages?

driven

it seems to be something to do with the dynamic loading...

selection toys image paths work...

all work here

thomthom

@driven said:

it seems to be something to do with the dynamic loading...

selection toys image paths work...

[attachment=0:1zv85099]selectionToys_path.png[/attachment:1zv85099]

This is so odd. I use webdialog.set_html to send it generated HTML. SU then makes a temp file out of that and loads it. So in theory it should not really make a difference... arrrgh... I'm getting flashbacks of IE-hell....

thomthom

@driven said:

it seems to be something to do with the dynamic loading...

selection toys image paths work...

How do you enable the debug panel in Webdialogs under OSX?

fredo6

@driven said:

it seems to be something to do with the dynamic loading...

selection toys image paths work...

This is rather good news!
At least we may have a first clue that it can work and try identifying a possible workaround.

As Thomthom said, there should be some Html files in the /tmp directory of your Mac (at least while the dialog box is opened). That would be great to get one for Selection Toys and one for a plugin which does not show images.

Alternatively, we could design a small dialog box test plugin showing only one image, so that the code is easier to debug.

Fredo

PS: I guess Safari 5.1 only comes with Lion. Is it correct?

thomthom

Fredo, you have similar problems? With dialogs that use .set_html instead of .set_file ?

thomthom

I just did a test, where instead of using my generated HTML with .set_html I wrote it to a temp file and used .set_file - everything worked fine again.

I really do not understand why it makes a difference, because what I just did as a workaround is exactly what SketchUp does internally with .set_html ...

fredo6

@thomthom said:

Fredo, you have similar problems? With dialogs that use .set_html instead of .set_file ?

I don't have Safari at hand (and anyway not Safari 5), so it is difficult to say anything.

While it is easy to write the HTML to a temp file and load it via set_file, the problem I see is for the refresh (I use set_html when the web dialog is opened). Maybe it will work as well.

Fredo

thomthom

@unknownuser said:

While it is easy to write the HTML to a temp file and load it via set_file, the problem I see is for the refresh (I use set_html when the web dialog is opened). Maybe it will work as well.

So you also use .set_html ?
I'll be looking into it closer to see if I can make it work with that method, otherwise I have to switch to making a temp file.

As you mention, if you delete the temp file while the window is open you break Refresh.
If you observe the tmep folder when you use .set_html you'll see that SU keeps the temp HTML file around until you call .set_html again for that window object or until SU closes, where it cleans up all tmep files.

Making a cleanup operation from Ruby won't be so easy I think...

thomthom

I tried this:


w=UI;;WebDialog.new "Hello"
#<UI;;WebDialog;0x5ff2fa8>

w.set_html "Hello"
nil

GC.start
nil

w=nil
nil

GC.start
nil

When I invoke CG.start the temp file is erased.
I wonder if it's possible to be notified in Ruby when an object is garbage collected...

thomthom

Maybe this: http://www.ruby-doc.org/core-1.8.6/classes/ObjectSpace.html#M001111 ?

With a gotcha: http://www.mikeperham.com/2010/02/24/the-trouble-with-ruby-finalizers/

fredo6

Before going too far and change the method of building web dialogs, let's try to find out why images cannot be loaded on Safari 5, whereas

it works fine on previous versions of Safari (but we need the file:// prefix)
it works fine on IE, any version (prefix file:// not required).

So far, the problem seems to be related to the security of Safari or Lion, since the message is that access to local resources is not allowed. And what we just found out is that Safari would react differently is the web dialog is loaded via set_html vs. set_file.

The question is why? By the way, did you try with loading a HTML file from the /tmp directory with set_file?

Fredo

PS: It is true that the browser designers primarily think about 'connected' web pages, with a real web servers, not using HTML and JS as a simple way to build GUI locally on the PC, without any remote connection and web site. Added to that Apple is known to pay relatively little attention to backward compatibility.

Fredo

thomthom

@unknownuser said:

So far, the problem seems to be related to the security of Safari or Lion, since the message is that access to local resources is not allowed. And what we just found out is that Safari would react differently is the web dialog is loaded via set_html vs. set_file.

Strange new find:
w.set_html '<script>alert( window.location )</script>'

Under Windows:
This presents a messagebox with a string to a temp file.

Under OSX with Safari 5.0.6 the messagebox yields "about:blank"
I wonder if that was the case in previous version. Now I can't test...

@unknownuser said:

The question is why? By the way, did you try with loading a HTML file from the /tmp directory with set_file?

That's the thing - I can't find what temp location SU writes to now as window.location reports nothing...

ENV['TMPDIR'] yields /var/folders/jw/jwKHMuVxGEi4OILNAxFfgU+++TI/-Tmp-/
I can't even find that on the disk...