[webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

[Mihai Parparita]

Joseph said "there is a proprietary web app that relies on this, but it
is used at a small company I no longer work for and have no access to" and
did report the original bug, so that would appear to be a real-world bug.

My understanding is that the the log spam problem is annoying for teams that
use certain elements on the Google Talk browser widget, since it ends up
triggering that message frequently. Same for sites that include ads (e.g. in
my past life working on Google Reader, it was annoying to have this message
from iframe-based ads that tried to reach into the parent crowd out my own
logging). Users and semi-knowledgeable developers also seem confused by it,
given http://crbug.com/31068 and http://crbug.com/43173.

I'm not arguing for the logging to be removed entirely, I'm just hoping that
it can be tied to the exception (that should be thrown), so that if the
developer is expecting it to happen in certain cases, they can suppress it.

Mihai

On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig <sam.weinig at 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.
>
> I agree with Maciej that the current behavior is in many ways better, so I
> am not in a rush to change this just to be more spec compliant.
>
> -Sam
>
> On Mon, Aug 16, 2010 at 1:50 PM, Mihai Parparita <mihaip at chromium.org>wrote:
>
>> I was wondering if there are any other thoughts on this. It seems like
>> there's real-world need from this (based on the usages I tracked down, and
>> log spam problem) and all other browsers (and the HTML5 spec) have the
>> exception-throwing behavior.
>>
>> Thanks,
>> Mihai
>>
>>
>> On Fri, Aug 13, 2010 at 10:19 AM, Mihai Parparita <mihaip at chromium.org>wrote:
>>
>>> On Fri, Aug 13, 2010 at 9:59 AM, Mihai Parparita <mihaip at chromium.org>
>>> wrote:
>>> > I've asked Joseph (the original reporter of http://crbug.com/17325)
>>> > where he ran into this.
>>>
>>> Joseph replied and said "While there is a proprietary web app that
>>> relies on this, but it is used at a small company I no longer work for
>>> and have no access to. However, I do remember it being a little
>>> frustrating developing around this since Firefox and IE both throw the
>>> exception."
>>>
>>> The other reason why throwing the exception might be preferable is to
>>> avoid console log "spam". For example, http://www.nytimes.com/ has
>>> lots of iframes that (for whatever reason) reach into the parent (or
>>> vice-versa). In Safari and Chrome, the console has 6 "unsafe
>>> JavaScript access" messages, which the developer can't avoid, even if
>>> they're expecting possible errors (in Firefox there's only 1, so I
>>> assume at least some of their JS has try/catch blocks around
>>> cross-origin access). If we replace the printErrorMessageForFrame call
>>> with setDOMException(exec, SECURITY_ERR) then developers who catch the
>>> exception can avoid the log message.
>>>
>>> Mihai
>>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100816/5e8e2ab9/attachment.html>