WebDialog.set_html fails under Safari 5.0.6

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

thomthom

Found one of my older posts - I'd forgotten about.
http://forums.sketchucation.com/viewtopic.php?f=180&p=306204#p306122

Similar, expect that I made it work with file:// - now that seems to have been closed down as well.

driven

@thomthom said:

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

the path to the -Tmp-
Macintosh HD/private/var/etc...

private is a hidden folder

the easiest way to expose hidden folders is HiddenFiles widget softpedia has it

I've got both versions of Safari if you want me to test things..

@fredo, I'll pm you after I test on 5.0.6

driven

@thomthom said:

Similar, expect that I made it work with file:// - now that seems to have been closed down as well.

I think a load or reload button may be required or a least help debug, sort of got Fredo's working now.

thomthom

@driven said:

@thomthom said:

Similar, expect that I made it work with file:// - now that seems to have been closed down as well.

I think a load or reload button may be required or a least help debug, sort of got Fredo's working now.

driven

sorry, it was late and I didn't explain anything...

Fredo made some tweeks and I was doing the mac testing.

when either fredo's LibFredo6 settings dialog or Cleanup3 dialog are first opened they show in WebInpector Resources as (about:blank)
initial load of either

(about:blank) pages can't be reloaded using normal right-click reload, however with fredo's if you make a selection that forces a content reload like changing the parramaters, (about:blank) is replaced by the proper page, the errors disappear and everything works.

after changing checkbox selection

with Cleanup3 there is nothing to click that will force a change, to see if it would then reload properly.

sorry if my logic is flawed, but hopefully this explains what I mean.

john

thomthom

I split of the discussion for this particular issue as it's a problem with the WebDialog class itself and not the plugin in itself.

Dan Rathbun

Didn't John do some testing awhile back where he had to use " file://localhost/" or similar ?

What if the resources were in the user's path.. " **~**/Library/Application Support/...etc."

thomthom

@dan rathbun said:

Didn't John do some testing awhile back where he had to use " file://localhost/" or similar ?

Yes, but now even that fails.

Dan Rathbun

@thomthom said:

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

Don't overlook the Standard Library... " tmpdir.rb" and " tempfile.rb"

Dan Rathbun

Been having similar problems trying to run a local copy of firebug... looks like it's time to set up a simple server. I think Dan Berger has one in the win32-api package.

fredo6

@thomthom said:

I split of the discussion for this particular issue as it's a problem with the WebDialog class itself and not the plugin in itself.

I agree, and before we engage in workarounds and other approximate fixing, we really need to understand where the issue comes from and why it does materialized differently in two versions of Safari which should not be so different (5.03 and 5.06, correct?).

In any case, we need to hear from the SU team, because they must have an idea of how the web dialogs are integrated with Safari on Mac and clarify why security is handled differently by a set_html and a set_file.

Fredo

TIG

Isn't it that there are three different BUT 'related' .set_ methods?

**WebDialog.set_file** Used to set a *local* HTML file to display in the webdialog. Arguments: filename = The filename for the webdialog file (HTML file). path = (optional) A path to which the filename is relative. Returns: nil Usage: dialog.set_file("C:\\Temp\\mypage.html")

OR
**WebDialog.set_html** Used to load a string of *HTML code* into the webdialog. Arguments: html_string = A string of valid html to display in your webdialog. Returns: nil Usage: dialog.set_html("Hello world!")

OR
**WebDialog.set_url** Used to load a specific *URL* into the webdialog, i.e. it loads a *web-site* into the webdialog. Arguments: url = The URL for a specific web site. Returns: nil Usage: dialog.set_url("http://www.google.com")

They are not meant to be interchangeable

thomthom

TIG: The problem is that when you use .set_html you do not get access to local resources any more under OSX Safari 5.0.6+.