On Thu, Mar 22, 2012 at 9:21 PM, Adam Barth <aba...@webkit.org> 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. > Let's suppose I have some unannounced product like unannounced.google.comand say it embeds an iframe. Isn't it a information disclosure issue that anyone can now detect the usage of unannounced.google.com when they are framed (especially if "unannounced" were more descriptive)? dave > > Adam > > > On Thu, Mar 22, 2012 at 9:16 PM, David Levin <le...@chromium.org> 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 <wei...@apple.com> 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 <le...@chromium.org> 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 <sam.wei...@gmail.com> > 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 > >> webkit-dev@lists.webkit.org > >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >> > >> > > > > > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev