Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses
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.
There is definitely a bug and a real-world use case for this for WebKit. At Sprout (http://sproutinc.com) we have a generic platform to design mobile HTML5 ads which are served inside an IFRAME. We allow designers to link elements in top window and new window. If they choose "top window", in Android 2.2 when we do "window.top.location.href = url" instead of going to the URL or just halting code execution, the browser refreshes the current top-level page. We need a way to test for the security exception or at least detect some other property of window.top and then do window.open(url) instead when that security error is trapped or we detect different-origin. -- Rob Barreca Director of Development Sprout, Inc. Mobile: 808.224.1905 Confidential and Proprietary Property of Sprout; Do not distribute. The information contained in this email is confidential. This information is intended for use only by the individual to whom it is addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication and its contents is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email and attachments, and destroy all copies.
On Aug 25, 2010, at 6:06 PM, Rob Barreca wrote:
We need a way to test for the security exception or at least detect some other property of window.top and then do window.open(url) instead when that security error is trapped or we detect different-origin.
Does checking the value of window.top.location.href afterward work? Or maybe that doesn’t happen until some unpredictable amount of time later when the load makes progress? -- Darin
On Wed, Aug 25, 2010 at 3:23 PM, Darin Adler <darin@apple.com> wrote:
Does checking the value of window.top.location.href afterward work? Or maybe that doesn’t happen until some unpredictable amount of time later when the load makes progress?
Hey Darin, thanks for the reply. Unfortunately checking the href afterward does not work. A couple problems, (1) we can't access the value at all because the browser prevents the actual reading of the value since window.top is different-origin so it comes back empty string, and even if we could read the href the big problem at least in Android 2.2 is that (2) the browser refreshes the page when the unsafe JS access happens so the user is already being navigated away in essence. Right now we have a big hack detecting Android 2.2 and always opening links with window.open(), but I know there are other WebKit use-cases we'll need to account for that we haven't got a good repro on yet. Being able to detect different-origin cases ahead of time (or try/catch) would really improve the user experience of this IFRAMEd content. Best, -- Rob Barreca Director of Development Sprout, Inc. Mobile: 808.224.1905 Confidential and Proprietary Property of Sprout; Do not distribute. The information contained in this email is confidential. This information is intended for use only by the individual to whom it is addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication and its contents is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email and attachments, and destroy all copies.
(1) we can't access the value at all because the browser prevents the actual reading of the value since window.top is different-origin so it comes back empty string,
Isn't empty string sufficient to indicate lack of access? What unique information does an exception provide?
and even if we could read the href the big problem at least in Android 2.2 is that (2) the browser refreshes the page when the unsafe JS access happens so the user is already being navigated away in essence.
Can you provide more information about this? Is this intentional behavior, or just a bug in Android? Does the browser refresh upon reads and writes of location.href, or only writes? Thanks, Geoff
On Thu, Aug 26, 2010 at 7:20 AM, Geoffrey Garen <ggaren@apple.com> wrote:
Isn't empty string sufficient to indicate lack of access? What unique information does an exception provide?
Sorry for the delay in my response. Had a big couple weeks there. So initially, I was testing for empty string but in all instances of iOS and Android I would get the empty string back. This is correct behavior since I was trying to read a different-origin parent's URL, which shouldn't be allowed. But that didn't give me enough information. The problem in our scenario is that even though I cannot *read *top.location.href in all versions of iOS and Android, all of those environments will allow me to *write* top.location.href and send the user away...except for Android 2.2. So I suppose my hope was that an exception while attempting to *write* would let me know that the write was going to fail, and I should do window.open(url) instead. It's not a huge problem and it seems technically we should just by defaulting to window.open(url) even though most mobile environments allow writing to top.location.href even if the top window is different-origin.
and even if we could read the href the big problem at least in Android 2.2 is that (2) the browser refreshes the page when the unsafe JS access happens so the user is already being navigated away in essence. Can you provide more information about this? Is this intentional behavior, or just a bug in Android?
So after thinking about it more, my problem is that Android 2.2 is dealing with the write in a weird way versus previous Android versions and iOS.
Does the browser refresh upon reads and writes of location.href, or only writes?
Only writes, when I wrote "access" in the last email I meant "write". Best, -- Rob Barreca Director of Development Sprout, Inc. Mobile: 808.224.1905 Confidential and Proprietary Property of Sprout; Do not distribute. The information contained in this email is confidential. This information is intended for use only by the individual to whom it is addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication and its contents is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email and attachments, and destroy all copies.
participants (3)
-
Darin Adler
-
Geoffrey Garen
-
Rob Barreca