It depends. We discovered that the brokenness was the result of the AdBlock extension that Chris had installed. This was orthogonal to the Firebug output.
The Firebug output is annoying, but innocuous: it doesn't break anything. I argue, based on my current understanding, that the bug here is in Firebug. It shouldn't report a properly caught exception. But the opposing view is that Firebug is popular enough that this annoying output is disconcerting, so we need to change our implementation (to a parent-param-based approach) to obviate the issue altogether. I find this highly unsatisfying (since Firebug reportedly does this in lots of other random situations), but I understand the argument. Viz. Shindig's functionality, however, there's no breakage, and Chris is freed up. John On Fri, Dec 5, 2008 at 2:43 PM, Dan Peterson <[EMAIL PROTECTED]> wrote: > *Chris, John,* > *What's the next step here? How can we close out this bug to push forward > with the rc?* > > *-Dan > * > On Thu, Dec 4, 2008 at 12:10 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > > > 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 > > >> > > > > >> > > > >> > > > > > > > > >
