it could be added that some people would argue that the try/catch isn't the cleanest way to check if the domains are the same, but instead should do a compare on protocol / host, however as John wrote the bug is now non-fatal, so not blocking any more!
In my test scenario firebug was showing the exception, and adblock was crashing on it (don't ask, i have no clue why), which lead me to believe it was a general fatal bug (though of course that extension is used quite a bit in the wild, so worth keeping this bug in mind). In short: RC is go! On Fri, Dec 5, 2008 at 11: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 > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > > >
