WebDialog.set_html fails under Safari 5.0.6

driven

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

selection toys image paths work...

all work here

thomthom

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

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.