I've started a thread on whatwg in case folks with like to discuss this topic further:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035188.html Thanks, Adam On Thu, Mar 22, 2012 at 9:21 PM, Adam Barth <[email protected]> wrote: > I wonder if we could expose the parent document's origin, so you could > write the check as follows: > > if (parent.location.origin != location.origin) > return; > > It's slightly subtle because we wouldn't want to expose the origin of > child frames (then you could probe the redirect structure of private > networks), but exposing ancestor origins seems tenable. > > Adam > > > On Thu, Mar 22, 2012 at 9:16 PM, David Levin <[email protected]> wrote: >> Suppose I am using a framework does window.frameElement for various >> reasons. When that framework is used in an iframe, it causes errors to >> appear in the console. >> >> For example, suppose the framework does this: >> >> var a; >> try { >> a = window.frameElement; // WebKit outputs a console error here. >> if (!a) >> return; >> } catch (e) { >> return; >> } >> ... >> >> >> Now if I had this new method, I would change the framework to do this: >> >> var a; >> try { >> // WebKit doesn't throw an exception for x-origin parent access, but it >> will puts errors in the console. >> // Do an explicit access check to avoid having the error appear in the >> console. >> var canAccessParent = window.parent.webkitCanAccess; >> if (canAccessParent != undefined && !canAccessParent) >> return; >> a = window.frameElement; >> if (!a) >> return; >> } catch (e) { >> return; >> } >> ... >> >> >> Does that help? (The use case is about avoiding spurious console error >> messages, so console error messages are real errors.) >> >> dave >> >> >> On Thu, Mar 22, 2012 at 8:44 PM, Sam Weinig <[email protected]> wrote: >>> >>> Hey Dave, >>> >>> Can you describe the use case for this new property? When would an author >>> use it? >>> >>> -Sam >>> >>> On Mar 22, 2012, at 4:16 PM, David Levin <[email protected]> wrote: >>> >>> Resurrecting a really old thread so continue the conversation now that I'm >>> hitting this issue :). >>> >>> On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig <[email protected]> wrote: >>>> >>>> I am not sure I agree. Does our behavior actually cause any real bugs in >>>> the places you have tracked down? The log spam really doesn't seem like an >>>> issue, we can remove it if we want to, but have found it useful in the >>>> past. >>> >>> >>> Speaking as someone who working on a web app, the log spam is >>> a significant issue because: >>> >>> It clutters up the console output making it harder to find the real error. >>> (It is hard to explain how much worse this makes the experience until you >>> have to deal with a sophisticated web page. Image looking at the logs from >>> your app and seeing lots of error messages -- many of which are this one and >>> then a real one hidden among them -- from personal experience.) >>> When more sophisticated end users see it, they think there is a problem in >>> the app and report it (and it could be that they include this in their error >>> report and ignore other more important things). >>> >>> I understand that that the console/log spam is useful to detect real >>> issues as well (given that WebKit doesn't throw an exception in this case). >>> >>> Would people find it acceptable to have window.webkitCanAccess so that a >>> web page can use that property first to detect the cross origin issue and >>> avoid doing an access which would trigger the console spam? (I would also be >>> fine with an exception instead of log spam.) >>> >>> Thanks, >>> dave >>> >>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
