Re: [whatwg] MessageEvent.domain, document.domain on a page whose URI has no domain (e.g. data:text/html, ...)
On Jan 24, 2008 10:59 AM, Jonas Sicking <[EMAIL PROTECTED]> wrote: > Note that this is a much bigger issue than simply what to return for > document.domain. It's basically the question, what security context > should data: documents and written-into documents use. The security origin of frames that begin life with the URL "about:blank" or "" differs in different browsers. In Firefox and the trunk revision of WebKit, the principal for the frame is aliased to the principal of the frame's parent (or opener, if it is a top-level frame). In IE7, the frame appears to copy the principal. http://crypto.stanford.edu/~abarth/research/html5/empty-frame/ The frame's window.location.href property matches the parent/opener in Firefox, IE, and Safari: http://crypto.stanford.edu/~abarth/research/html5/empty-frame/href.html Adam
Re: [whatwg] MessageEvent.domain, document.domain on a page whose URI has no domain (e.g. data:text/html, ...)
Jeff Walden wrote: The spec as currently written says that document.domain in a document located at a URI with no domain is null: data:text/html,alert(document.domain); Safari and Opera both alert the empty string for this; Firefox alerts null. There's also a domain property on MessageEvent, used with the cross-document postMessage API. The exact value of this property isn't quite clear in the current spec (which says the document has no domain but doesn't say what that translates into on the MessageEvent interface), but Opera and Safari both agree that the domain property should be the empty string when the page that calls postMessage is a data: URL. It seems that, for consistency, document.domain and MessageEvent.domain should both be the empty string in this case, for greatest cross-browser compatibility with the least change to the status quo, with the only change needing to happen in Firefox. Note that this is a much bigger issue than simply what to return for document.domain. It's basically the question, what security context should data: documents and written-into documents use. / Jonas
Re: [whatwg] MessageEvent.domain, document.domain on a page whose URI has no domain (e.g. data:text/html, ...)
On 1/23/08, Jeff Walden <[EMAIL PROTECTED]> wrote: > The spec as currently written says that document.domain in a document located > at a URI with no domain is null: > > data:text/html,alert(document.domain); > > Safari and Opera both alert the empty string for this I like Safari and Opera's way because .domain always returns a string, which makes sense to me from a type perspective (at least in javascript). However, Firefox is probably right because in the case of no domain, there's no domain string to return, so null is returned. This is also what PHP's DOMDocument->domain returns. Just would be nice if all browsers did the same here. -- Michael
[whatwg] MessageEvent.domain, document.domain on a page whose URI has no domain (e.g. data:text/html, ...)
The spec as currently written says that document.domain in a document located at a URI with no domain is null: data:text/html,alert(document.domain); Safari and Opera both alert the empty string for this; Firefox alerts null. There's also a domain property on MessageEvent, used with the cross-document postMessage API. The exact value of this property isn't quite clear in the current spec (which says the document has no domain but doesn't say what that translates into on the MessageEvent interface), but Opera and Safari both agree that the domain property should be the empty string when the page that calls postMessage is a data: URL. It seems that, for consistency, document.domain and MessageEvent.domain should both be the empty string in this case, for greatest cross-browser compatibility with the least change to the status quo, with the only change needing to happen in Firefox. Jeff
