Cool. RC++ -Dan
On Fri, Dec 5, 2008 at 2:49 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > 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 >> > >> > > >> > >> > >> > >> >> > > >> > > >> > >> > >
