Aha - so this is Firebug reporting a caught exception that is nevertheless functionally innocuous.
This error in general shows up in various places, such as implicating Flash: http://willperone.net/Code/as3error.php In this case, perhaps Flash is invoking adjustHeight, the context of which call causes Firebug (for reasons I don't deeply understand right now) to catch and report the exception rather than (arguably, appropriately) fall through. --John On Thu, Dec 4, 2008 at 11:46 AM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > 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 >> > > >> > >> > >
