<br><br><div class="gmail_quote">On Fri, Mar 23, 2012 at 12:13 PM, Adam Barth <span dir="ltr"><<a href="mailto:abarth@webkit.org">abarth@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<p>That's a risk, but you could also worry that the name would leak in the iframe's document.referrer property.</p></blockquote><div>Frankly, I'm in favor of anything to help me get rid of the console error :).</div>

<div><br></div><div>I was concerned that exposing the parent origin has complications that will make it harder for this to get into WebKit, etc. but if folks find that acceptable, it scratches my itch.</div><div><br></div>

<div>dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
<p>Adam<br>
</p></font></span><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Mar 23, 2012 12:02 PM, "David Levin" <<a href="mailto:levin@chromium.org" target="_blank">levin@chromium.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br><br><div class="gmail_quote">On Thu, Mar 22, 2012 at 9:21 PM, Adam Barth <span dir="ltr"><<a href="mailto:abarth@webkit.org" target="_blank">abarth@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




I wonder if we could expose the parent document's origin, so you could<br>
write the check as follows:<br>
<br>
if (parent.location.origin != location.origin)<br>
    return;<br>
<br>
It's slightly subtle because we wouldn't want to expose the origin of<br>
child frames (then you could probe the redirect structure of private<br>
networks), but exposing ancestor origins seems tenable.<br></blockquote><div><br></div><div>Let's suppose I have some unannounced product like <a href="http://unannounced.google.com" target="_blank">unannounced.google.com</a> and say it embeds an iframe.</div>




<div><br></div><div>Isn't it a information disclosure issue that anyone can now detect the usage of <a href="http://unannounced.google.com" target="_blank">unannounced.google.com</a> when they are framed (especially if "unannounced" were more descriptive)?</div>




<div><br></div><div>dave </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
Adam<br>
</font></span><div><div><br>
<br>
On Thu, Mar 22, 2012 at 9:16 PM, David Levin <<a href="mailto:levin@chromium.org" target="_blank">levin@chromium.org</a>> wrote:<br>
> Suppose I am using a framework does window.frameElement for various<br>
> reasons. When that framework is used in an iframe, it causes errors to<br>
> appear in the console.<br>
><br>
> For example, suppose the framework does this:<br>
><br>
> var a;<br>
> try {<br>
>     a = window.frameElement; // WebKit outputs a console error here.<br>
>     if (!a)<br>
>         return;<br>
> } catch (e) {<br>
>     return;<br>
> }<br>
> ...<br>
><br>
><br>
> Now if I had this new method, I would change the framework to do this:<br>
><br>
> var a;<br>
> try {<br>
>     // WebKit doesn't throw an exception for x-origin parent access, but it<br>
> will puts errors in the console.<br>
>     // Do an explicit access check to avoid having the error appear in the<br>
> console.<br>
>     var canAccessParent = window.parent.webkitCanAccess;<br>
>     if (canAccessParent != undefined && !canAccessParent)<br>
>         return;<br>
>     a = window.frameElement;<br>
>     if (!a)<br>
>         return;<br>
> } catch (e) {<br>
>     return;<br>
> }<br>
> ...<br>
><br>
><br>
> Does that help? (The use case is about avoiding spurious console error<br>
> messages, so console error messages are real errors.)<br>
><br>
> dave<br>
><br>
><br>
> On Thu, Mar 22, 2012 at 8:44 PM, Sam Weinig <<a href="mailto:weinig@apple.com" target="_blank">weinig@apple.com</a>> wrote:<br>
>><br>
>> Hey Dave,<br>
>><br>
>> Can you describe the use case for this new property?  When would an author<br>
>> use it?<br>
>><br>
>> -Sam<br>
>><br>
>> On Mar 22, 2012, at 4:16 PM, David Levin <<a href="mailto:levin@chromium.org" target="_blank">levin@chromium.org</a>> wrote:<br>
>><br>
>> Resurrecting a really old thread so continue the conversation now that I'm<br>
>> hitting this issue :).<br>
>><br>
>> On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig <<a href="mailto:sam.weinig@gmail.com" target="_blank">sam.weinig@gmail.com</a>> wrote:<br>
>>><br>
>>> I am not sure I agree.  Does our behavior actually cause any real bugs in<br>
>>> the places you have tracked down?  The log spam really doesn't seem like an<br>
>>> issue, we can remove it if we want to, but have found it useful in the<br>
>>> past.<br>
>><br>
>><br>
>> Speaking as someone who working on a web app, the log spam is<br>
>> a significant issue because:<br>
>><br>
>> It clutters up the console output making it harder to find the real error.<br>
>> (It is hard to explain how much worse this makes the experience until you<br>
>> have to deal with a sophisticated web page. Image looking at the logs from<br>
>> your app and seeing lots of error messages -- many of which are this one and<br>
>> then a real one hidden among them -- from personal experience.)<br>
>> When more sophisticated end users see it, they think there is a problem in<br>
>> the app and report it (and it could be that they include this in their error<br>
>> report and ignore other more important things).<br>
>><br>
>> I understand that that the console/log spam is useful to detect real<br>
>> issues as well (given that WebKit doesn't throw an exception in this case).<br>
>><br>
>> Would people find it acceptable to have window.webkitCanAccess so that a<br>
>> web page can use that property first to detect the cross origin issue and<br>
>> avoid doing an access which would trigger the console spam? (I would also be<br>
>> fine with an exception instead of log spam.)<br>
>><br>
>> Thanks,<br>
>> dave<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> webkit-dev mailing list<br>
>> <a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
>> <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> webkit-dev mailing list<br>
> <a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
> <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
><br>
</div></div></blockquote></div><br>
</blockquote></div>
</div></div></blockquote></div><br>