Jul 282008

In the fall of 2006 I was wrestling with VS debugging JavaScript in IE and Venkman in Firefox teasing out problems and holes in the cross-domain channel library we were building for Windows Live and the Windows Live Contacts Control.

One of the most aggrevating aspects of debugging cross-domain JavaScript is that JavaScript debuggers do not provide the same degree of omniscience we have come to expect from full-featured desktop application debuggers. The reason is that the debugger operates inside the browser, rather than above the browser.  To evaluate an expression, the debugger has to ask the browser’s JavaScript engine for the element values, or to evaluate the expression itself. Since the debugger is relying on the browser for evaluation, and the browser has access firewalls all over the place to implement same-domain policy restrictions, the debugger can’t see anything more than what the JavaScript itself can see.  A debugger attached to the execution context of a top level HTML page can’t see inside the iframes sitting on that page if the iframes are showing pages from a different domain.

This is fixable, but I doubt that it will ever be fixed. I suspect it would be a major restructuring of the browser code to allow a debugger to circumvent the browser’s security restrictions and see JavaScript state from all domain contexts concurrently. Even just a casual mention of this idea to Mozilla or Microsoft browser teams draws up such fear in their eyes that you change the subject to avoid someone going postal. I can’t really blame them – both browser code bases are huge and hairy, and infamous for inflicting great gouts of pain on well-meaning tinkerers who venture too far into the forest. 

Besides, it’s fair to say that the browser teams’ first priority is data security and safety. Omniscient debugger support is understandably lower on their priority list.

At any rate, while I was poking and prodding my cross-domain experiments trying to get a mental picture of how code reality was diverging from the whiteboard spec, I would occasionally notice an odd artifact out of the corner of my evaluator.  Well, this is JavaScript – odd side effects are the norm. On one of these sorties I noticed that the window.name property was preserved across reloads of an iframe.

Now that’s odd.

My tinkering took off on a wild tangent.  Passing a lot of data in one string and round-trip would certainly be faster than doing it in multiple smaller round trips required by fragment identifier messaging (FIM).  However, the more I dug into it the more I found that needed to be chased down.  Frustrated and out of time, I pushed a note onto the “investigate this further” queue and forced myself back onto the plan of record.

Fast forward to 2008.  Kris Zyp has implemented a cross-domain transport for the Dojo JavaScript library using window.name. Kudos to Zyp for doing the legwork to turn the window.name oddity into a usable data transport pipe and shore up the holes and security vulnerabilities of the raw technique. 

I read his post (discovered via Ajaxian) with skepticism, armed with an array of  “Yeah, but what about…” challenges and security issues I vaguely recall running into in my late night tangent.  Zyp knocked them all down one by one in his detailed writeup.

Well done!

  3 Responses to “Cross-Domain Transport with Window.Name”

  1. One side note: I don’t think Zyp’s window.name will work in Safari because it relies on iframe onLoad events. Safari doesn’t have a great track record with onLoad events.

  2. […] – Using Breakpoint Hit Count For Fun And Profit.>> saved by GlossyiceIris 37 days ago3 votesCross-Domain Transport with Window.Name>> saved by slashdotdash 38 days ago5 votesJava Debug 101>> saved by momahoney 43 days ago6 […]

  3. […] public links >> crossdomain Cross-Domain Transport with Window.Name First saved by luvstodream | 10 days ago “Security error accessing url” in Flash 9,0,124,0 […]

Sorry, the comment form is closed at this time.