Hello, I've found that cross-frame scripting is not working in Safari 3.0.4, as it worked ok on Safari 3.0.1, and in other browsers I tried: Firefox, Mozilla, IE. document.domain property is set to "ds2ps.net", correctly to the best of my knowledge in the frameset and in both frames. Both frames and frameset are loaded from subdomains of the same domain "ds2ps.net" Please have a look at this mimimal example: http://frameset.ds2ps.net/frames-test/frameset.html Press buttons to get alert with value of a variable defined in the frameset and in the first frame. This gives "undefined" in Safari 3.0.4, and give following message in Safari JavaScript console: Unsafe JavaScript attempt to access frame with URL http://frameset.ds2ps.net/frames-test/frameset.html from frame with URL http://frame2.ds2ps.net/frames-test/frame2.html. Domains, protocols and ports must match. Works ok in all other browsers and in earlier versions of Safari. I would appreciate if Apple Safari developers have a look at this problem and suggest solution. My company is developing web application which depends on cross-frame scripting, and we would like to continue supporting Safari browser. Thank you.
Created attachment 17899 [details] Minimal testcase to demonstrate inability to access other frames with same document.domain See the README.txt file in the archive. To run this example on your server: =================================== - create 3 subdomains on your test domain: frameset.yourdomain.com, frame1.yourdomain.com, frame2.yourdomain.com - Modify src addresses of frames in the frameset.html to reflect your domains. - Modify document.domain clauses in all 3 pages from "ds2ps.net" to your base domain "yourdomain.com" - Upload all three pages on your server and access as http://frameset.yourdomain.com/frames-test/frameset.html If you have any questions, please email to s.skugarev@providesupport.com or call 1-646-472-5881. Thank you.
This doesn't seem to fail in ToT. Could you try and test it in the nightly and see if the problem persists?
(In reply to comment #2) > This doesn't seem to fail in ToT. Could you try and test it in the nightly and > see if the problem persists? Nightly builds are at: http://nightly.webkit.org/
Thank you, Sam Weinig and David Kilzer, I'm happy to confirm that this problem doesn't exist in the nightly build for Windows. Can't check on Mac right now, but I hope it was fixed in Mac version as well. Now the question is when this code will become available through Mac auto-update system. Hundreds of our customer who downloaded automatic update few weeks ago started experiencing this problem, and they are not able to use our product since that time. We and our customers would be highly interested if this update is available as soon as possible. Thank you, Sergiy Skugaryev
(In reply to comment #4) > Thank you, Sam Weinig and David Kilzer, > > I'm happy to confirm that this problem doesn't exist in the nightly > build for Windows. Can't check on Mac right now, but I hope it was fixed > in Mac version as well. > > Now the question is when this code will become available through Mac > auto-update > system. Hundreds of our customer who downloaded automatic update few weeks > ago started experiencing this problem, and they are not able to use our product > since that time. We and our customers would be highly interested if this update > is available as soon as possible. > > Thank you, > Sergiy Skugaryev I am also able to confirm that this bug does exist in Safari 3.0.4, but it would seem that it is FIXED in the Mac nightly build as well as the Windows nightly build as the previous poster noted.
Per comment #2 and comment #4 resolved as WORKSFORME.