WebDialog.set_html fails under Safari 5.0.6
-
a couple observation while trying to get my head around all of this.
firstly, in Apples and probably Googles eyes the title of this thread should probably be 'WebDialog.set_html finally works as expected under Safari 5.0.6'. It does not appear to be not considered a 'bug', but a security enhancement.
It seems to have been implemented in Safari 4, to stop about:blank pages pirating local files and that some problem/oversite has allowed files:/// and other anonymous url's to work with about:blank pages in SU WebDialog and other WebView apps.
I have a number of html editors and they use temp files written to the relative folder, so if I try to edit index.html (for example) all the links, src's, url's, etc.. all remain relative and are considered safe. if I open the temp from a different folder I get load errors.
Although I know temp files can be anywhere (with corrected links) I think they should be in the originating plugins subfolder if they are unavoidable.
I also think bypassing 'about:blank' completely by having an actual html file that is then updated dynamically is also preferable.
but, since I'm not writing the rubies, time permitting, I'll test whatever you want to try.
john
-
I'm implementing a workaround where I manually use a temp file and .set_file into a patch I hope to release very soon.
It seems that at implementation level of .set_html differs from OSX and Windows. Where under Windows they create a temp file and feed that file to the web control. Where under OSX this is not the case, which is why we get about:blank and therefore get affected by strengthens security controls.
-
That's nice but it will depend on your Library ?
Has anyone logged this with Google ?? I'd think they'd wish to release patches if Safari 5.0.6 will break WebDialogs on all Mac versions.
-
@dan rathbun said:
That's nice but it will depend on your Library ?
Has anyone logged this with Google ?? I'd think they'd wish to release patches if Safari 5.0.6 will break WebDialogs on all Mac versions.
The only thing you need to implement is
TT::System.temp_pathwhich returns the temp directory. Other than that, the code snipped I posted is standalone. -
Fixed a small bug in the sample code.
-
Not personal.. but I'd prefer to rely on "tmpdir.rb" in the Standard Lib.
-
@dan rathbun said:
Not personal.. but I'd prefer to rely on "tmpdir.rb" in the Standard Lib.
Sure, it's just a bare bone example. In fact, it'd probably be best to use
tempfile.rbto create the temp file as well. -
I did some further testing I found some issues which I addressed in my example: http://forums.sketchucation.com/viewtopic.php?f=180&t=39842&p=352375#p352375
.set_filedoesn't cause the content of the webdialog to update if the filename is the same. So I made the example generate a new file with a unique seed in the filename to ensure it's updated..set_fileand.set_urlnow immediately cleans up the temp file if.set_htmlwas used prior.No more references to my TT_Lib in the example.
Linked to the Standard Lib in the comments for more robust temp file handlers.
-
Can these meta tags be injected to prevent caching:
%(#8000BF)[<META HTTP-EQUIV="Pragma" CONTENT="no-cache"> <META HTTP-EQUIV="Expires" CONTENT="-1">] -
@dan rathbun said:
Can these meta tags be injected to prevent caching:
%(#8000BF)[<META HTTP-EQUIV="Pragma" CONTENT="no-cache"> <META HTTP-EQUIV="Expires" CONTENT="-1">]I did consider sending a refresh comment to JS, but I figured I'd follow the pattern of how
.set_htmlworks on Windows, which is creating a temp file with a unique name. -
@dan rathbun said:
Has anyone logged this with Google ?? I'd think they'd wish to release patches if Safari 5.0.6 will break WebDialogs on all Mac versions.
TT ?
-
I've not logged anything yet. Been bugging a couple to see if they could shed some light.
-
Driven: I implemented a patch. Update to TT_Lib 2.5.5
http://forums.sketchucation.com/viewtopic.php?f=323&t=30503 -
To all,
Can we summarize what is the problem and what could be the workaround.
From what Driven has signaled, there are problems in both 5.0.3 and 5.0.6 Safari versions.
Also it would be good to hear from the Google SU Team, as they can perfectly implement a central solution that makes
set_htmlwork.Fredo
-
@thomthom said:
I've not logged anything yet. Been bugging a couple to see if they could shed some light.
OK.. then your on "top of this"... I suppose "they'll" ask you to log a formal bug # if they don't do it themselves.
@Fredo.. agreed, and I hope they'll monitor this topic for ideas.
-
@unknownuser said:
Can we summarize what is the problem and what could be the workaround.
From what Driven has signaled, there are problems in both 5.0.3 and 5.0.6 Safari versions.I tried to summarize here: http://forums.sketchucation.com/viewtopic.php?f=180&t=39842&p=352375#p352375
Not sure about 5.0.3 - but there has been some discussions on how to format the URLs linking to local resources. We found that
file:///worked on both platforms. -
-
@thomthom said:
Not sure about 5.0.3 - but there has been some discussions on how to format the URLs linking to local resources. We found that
file:///worked on both platforms.The issue with file:// on Mac/Safari was already there since the beginning.
So at the end, the workaround is just to use
set_fileon Mac- which works on Safari 5.06 (and to be confirmed on 5.03)
- which also works on previous versions, though
set_htmlstill works in Safari up to 5.01
Is this correct?
Fredo
-
I've used a mix of
.set_htmland.set_filein my plugins and have not had any problems until 5.0.6 came out. -
@driven said:
TT_SelectionToys works EXCEPT for 'cheat sheet' which shows as about:blank and loads nothing, not even error messages, so may be a different issue.
I believe it's a different issue as it's an older plugin. Lets look away from this one.
@driven said:
TT_CleanUp3 all now work with the latest patch EXCEPT temp file are not purged on close of dialog or SU.
Really? They should be erased when SketchUp is exited. hmm... Gonna look at it again on my Mac.
Advertisement