I'm dubious.
I tested this on several browsers - including FF3, though not the latest
patch release - and it worked fine, and has been working fine for the past
several months. This change was submitted on July 17, and is in the line of
fire of every gadgets.rpc call on every browser (as Chris noted, it's right
there in call()). I have to believe that someone would have reported this
earlier if it were fundamentally broken. Plus, it's unclear to me why origin
exceptions would be uncatchable - do you have any documentation on this?
There are also some obvious issues with this backtrace being directly
implicated:
A) It has nothing to do with a Location object.
B) It's an assignment, not a function call.
C) Even if it were a function call, it has nothing to do with .toString,
unless there are some really funky FF3 internals going on here.
D) rpc.js hasn't changed at all recently.
I just whipped up (sadly, on an internal-only setup) a test of this
technique in isolation and successfully tested it on FF2, FF3, Chrome, IE6,
IE8b2, Opera9, and Safari, all of which worked fine (caught the exception,
fell through without dying). The only difference between browsers is that
Safari/Chrome don't execute code in the catch-block.
I suppose it's possible that a different emitted header of some kind could
switch the JS runtime into "can't catch origin exceptions" mode, but even
that seems unclear to me. This very same error has been reported before, and
has always gone away for other reasons. I can't remember what those were
though -- researching...
--John
On Thu, Dec 4, 2008 at 11:03 AM, Chris Chabot <[EMAIL PROTECTED]> wrote:
> what happens is that call() (rpc.js) does:
>
> // If target is on the same domain, call method directly
> if (callSameDomain(targetId, rpc)) {
> return;
> }
>
> which does:
> try {
> // If this succeeds, then same-domain policy applied
> sameDomain[target] = targetEl.gadgets.rpc.receiveSameDomain;
> } catch (e) {
> // Usual case: different domains
> }
>
> .. which isn't a catchable error, but instead should have the full compare
> of host/port/protocol between the parent param and the url that kevin
> mentions and only if they match callSameDomain..
>
> On Thu, Dec 4, 2008 at 7:56 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
>
> > The same domain check here is clearly broken and wrong. You can't catch a
> > same origin policy violation on most browsers.
> >
> > The only way to legitimately check that it's the same origin ("same
> > domain")
> > is to require that the host, port, and protocol of the parent parameter
> > match that of the current domain, and then just assume that it's ok to
> fail
> > if the parent page is lying about its own value.
> >
> > On Thu, Dec 4, 2008 at 12:54 AM, Chris Chabot <[EMAIL PROTECTED]>
> wrote:
> >
> > > Hey guys, I *thought* I was all ready to go for a 1.0.0 release, every
> > > little (but important) bug I knew of was fixed, but at the last moment
> a
> > > svn
> > > update broke something in (what seems to be) the RPC code.
> > >
> > > This bit of code:
> > > 9098 function callSameDomain(target, rpc) { 9090 if (typeof
> > > sameDomain[target] === 'undefined') {
> > > 9091 // Seed with a negative, typed value to avoid
> > > 9092 // hitting this code path repeatedly
> > > 9093 sameDomain[target] = false;
> > > 9094 var targetEl = null;
> > > 9095 if (target === '..') {
> > > 9096 targetEl = parent;
> > > 9097 } else {
> > > 9098 targetEl = frames[target];
> > > 9099 }
> > > 9100 try {
> > > 9101 // If this succeeds, then same-domain policy applied
> > > 9102 sameDomain[target] = targetEl.gadgets.rpc.receiveSameDomain;
> > > 9103 } catch (e) {
> > > 9104 // Usual case: different domains
> > > 9105 }
> > > 9106 }
> > >
> > > (sorry for the firebug line # spam) causes the following error in FF3:
> > >
> > > Permission denied to call method Location.toString
> > > callSameDomain()ifr?synd...375419175 (line 9102)
> > > call()()ifr?synd...375419175 (line 9248)
> > > adjustHeight()()ifr?synd...375419175 (line 9502)
> > > onLoadedData(Object responseItems_=Object
> > > globalError_=false)ifr?synd...375419175
> > > (line 10912)
> > > sendResponse()(Object 0=Object 1=Object 2=Object 3=Object 4=Object
> > > 5=Object)ifr?synd...375419175
> > > (line 7521)
> > > processNonProxiedResponse("
> > >
> > >
> >
> http://shindig/social/rpc?st=UXpWVHZ0TTElMkJQbk9MQjJFWXU1cEJmSjVuU1dHaGZQZ21mdVVWUktCY0xwZldYeWNVaXhpS0p4MGF3Qlpmemx3enRqQUJoUDlGTDBaejlwd0JIJTJGaWhWcGklMkJKOGd2RVdHWjdHZjVtc1BkRUF0Wmo3Z1VLNXZHc1RvcTBRd2pLSzhxYU0zb3F1S2plVGxBSzQ0ckE5ekdSZXVIdHF4TUo2RjUlMkJJRFdldlV6MjJHN2ZUQklCR29ubmFBcng4RDNKMFBNU2MwSFElM0QlM0Q%3D
> > > ", function(), Object CONTENT_TYPE=JSON METHOD=POST
> AUTHORIZATION=SIGNED,
> > > XMLHttpRequest)ifr?synd...375419175 (line 1603)
> > > (?)()()ifr?synd...375419175 (line 411)
> > > sameDomain[target] = targetEl.gadgets.rpc.receiveSameDomain;
> > >
> > > In safari and chrome (and presumably IE) this is working fine, so it's
> a
> > > FF3
> > > specific issue as far as i've been able to test.
> > >
> > > The problem is that this is breaking every major gadget that I can test
> > ...
> > > so a 'blocker' is not an understatement here.
> > >
> > > Unfortunately my knowledge of the RPC JS code is to limited to be able
> to
> > > say anything sensible about this, so I'm hoping someone with more of a
> > clue
> > > will be able to guess what's going on here!
> > >
> > > The problem is easily reproducible on:
> > > http://www.partuza.nl/profile/application/1/833/2992
> > >
> > > I'm not a 100% sure on what changed, but all I can offer is "It used to
> > > work" :)
> > >
> > > -- Chris
> > >
> >
>
