A quick web search on calculating browser window height reveals that different browsers have different ways to find the browser’s window client height.  In Netscape / Mozilla browsers, you can use window.innerHeight.  For IE, some sources suggest using document.body.offsetHeight, but I’ve found this falls short when the HTML content does not completely fill the browser window.  document.documentElement.clientHeight returns the actual window client height in IE.

The jQuery JavaScript library has some handy functions for calculating an element’s pixel location and pixel width and height, with or without consideration for borders, padding and margin.  $(“.myclass”).outerHeight() will give you the pixel height of the first element with a CSS class of “myclass”, including borders and margins.

$(“body”).outerHeight() returns the same value as document.body.offsetHeight, which will be less than the window height in a short HTML document and could be much larger than client height in a scrolling window.

Share/Bookmark

Whenever I visit my Google homepage now, I have to wade through 5 or 6 JavaScript error notifications before I can do anything.  I suspect the culprit is the Gmail gadget for the Google homepage, as I continue to get script errors while trying to browse email in-situ on the homepage.  The gmail gadget is also missing scrollbars on long messages. None of these problems are present when using Gmail itself, just when using the Google homepage.

As a developer, I have to have script debugging enabled in my browser.  This enables me to debug my web app code in the browser, but it also has the unfortunate side effect of pointing out JavaScript errors on every site I visit.  It’s surprising how much crappy code is out there in production.  Slashdot has degraded into the pretty much unusable range in recent months, and now the Google homepage / Gmail widget is following suit.

The script errors are not specific to IE.  Firefox 3 also notes 5 critical errors in its error console when navigating to my Google homepage. To Firefox’s credit, recording these script errors in a log rather than with popup dialogs is much less intrusive than IE, but that also means that significant script errors can go unnoticed by developers testing their web apps with Firefox.

The errors are:

Error: _IG_AddCustomEventHandler is not a function
Source File: http://www.google.com/ig/f/lZ_kPjC_O4s/lib/libcore.js
Line: 43

Error: _IG_AddEventHandler is not a function
Source File: http://www.google.com/ig/f/irJtX0bmDdM/lib/libdynamic-height.js
Line: 4

Error: _IG_Json is undefined
Source File: http://www.google.com/ig/f/_pVqt4t_Qx8/lib/libviews.js
Line: 1

Error: _IG_Prefs._parseURL is not a function
Source File: http://www.google.com/ig/f/lZ_kPjC_O4s/lib/libcore.js
Line: 78

Error: _IFPC is undefined
Source File: http://www.google.com/ig/f/irJtX0bmDdM/lib/libdynamic-height.js
Line: 2

So, to whoever turned on the new code a few days ago for either the Google Homepage or the Gmail widget for the homepage:  Please review your code and fix the crappy script that you’re dumping on us.  Your developer bretheren thank you for a speedy resolution so that we may get back to debugging our apps instead of debugging yours.

Share/Bookmark

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!

Share/Bookmark

In the “Dependencies” section of the article, Stefanov describes using the onLoad or onReadyStateChange events of the dynamically generated script tag to receive notification when that script has been loaded by the browser.  Once you know it’s loaded, then you know it’s safe to begin using the code it contains.

This works great for Firefox and IE, but fails completely in the Safari browser.  Safari doesn’t implement onLoad notifications for script tags.  This forces you to abandon the onLoad technique and instead use the technique of embedding something at the end of each script file to signal when the file has been loaded. 

The script libraries for the Windows Live sites use this technique – every source file contains a function call at the bottom that tells a central notifier that it has been loaded.  Other code can ask the notifier to signal them when a file or set of files have been loaded.  This works in all browsers without relying on diverging browser idiosyncracies. 

Unfortunately, this also requires that all the JavaScript you want to load dynamically (using this technique) knows about your particular load notification pattern.  If you want to dynamically load JavaScript from multiple libraries or authors, you will either end up with multiple notification systems (which should coexist peacefully) or you’ll have to modify those files to use your load notifier.  This is bad from a design standpoint because it requires that all your code modules have carnal knowledge of your application - erodes the modularity of the source files – or require that all your code modules follow the design patterns of a particular JavaScript toolkit, like DoJo or Prototype or YUI.  The latter isn’t a terrible tradeoff except that it limits your options.

 Discovered via a note by Steve Trefethen on FriendFeed.

Share/Bookmark

Cross-domain communication is usually discussed in the context of a browser client communicating to a web server that is different than the domain of the web page currently shown in the browser.  The browser client displays a page from server foo.com, and that page tries to access data on server bar.com.  This is forbidden by the same-origin browser security policy because bar.com isn’t foo.com.

Server Side Proxy

One relatively simple way to resolve this is to have the browser page request data from the page’s web server, and have the web server relay that request to the actual third party server.  The browser displays a page from foo.com, and that page makes a data request to foo.com which foo.com relays to bar.com.  Bar.com replies to foo.com, and foo.com forwards that response on to the browser client page to complete the circuit.

While this solution is simple and quite widespread today, it has some significant problems:

1. Scalability and Network costs:  The request and response travel across your server’s network twice.  Request in, request out, response in, response out.  Traffic on your server network grows four times faster than growth of your application use.  That means you’ll reach network saturation four times sooner than with other techniques, and you’ll pay four times more (in server network traffic costs) for the privilege.
2. Impersonating the user:  When your foo.com server makes a request to bar.com seeking data for the user, you’re essentially impersonating the end user.  If the data on bar.com requires any sort of user identification or authorization, your server side proxy suddenly jumps from super simple to super difficult.  It’s easy enough to ask the user to log in to bar.com, but your foo.com can’t see anything that goes on in bar.com.  In particular, foo.com cannot see whatever browser cookies that bar.com sets to indicate logged in state.  Thus, it will be next to impossible for foo.com to present the appropriate cookies or credentials in its http request to bar.com to make bar.com believe that the request is coming from the legitimate user.  And this should be difficult – this is nothing short of a man-in-the-middle attack on bar.com’s security!

So, server side proxies are a quick and dirty way to toss anonymous data around, but they don’t scale well and they hit a wall when the data requires authentication.

Web Sites With Subdomains

Web sites and web applications generally start out as simple beasts running on a single web domain (www.foo.com).  As the site grows in functionality and complexity, the incentives to break that site up into subdomains (downloads.foo.com, feedback.foo.com, images.foo.com) grows as well.  Perhaps your web site has a download area that needs to be optimized for large file transfers.  That would probably be easier to fine tune as a server or cluster dedicated to that function than to try to tune the entire web site for large file downloads.

Subdomains often sprout as a byproduct of a company’s internal structure.  It takes a lot more effort to coordinate updates to one central server shared by multiple departments on different schedules than for a department to own their own subdomain, nicely isolated from the rest of the company’s constant revisions.

Double Edged Sword

Domain isolation is convenient to let you get your work done independently of the noise going on in the rest of the company’s web presence, but also presents a new problem:  web pages served from your subdomain cannot share information with web pages served from other subdomains of your company.  If the user logs in to your company’s main page, the browser cookies representing that login state are not accessible to your subdomain.

Lowering the Domain Barrier

The major browsers support a technique around this quandary, to allow subdomains to operate as equals within a common shared context.  The HTML document object has a domain property which normally reflects the complete domain name of the server from which the HTML document was loaded. The browser will allow you to assign a subset of the current domain name to the document.domain property to indicate that you wish for the HTML document to be treated as though it were loaded from the parent domain.

So, an HTML page served from downloads.foo.com can assign document.domain = “foo.com” in a JavaScript code block.  From that point forward, browser domain security checks will treat that page as a peer of any page in the foo.com domain.

The browser will (should) only allow you to change the document.domain to a less specific version of your current domain.  one.two.three.foo.com could be lowered to foo.com, or could be lowered to three.foo.com.

The browser should not allow assignment of a top-level domain (domain suffix) to document.domain.  You should not be able to change a document domain from “one.foo.com” to “com”.  There have been browser bugs in this area in the past where a browser implementer mistakenly interpreted “top level domain” to mean “the bit of the domain after the last dot”.  “.com”, “.edu”, and “.org” are top level domains, but “.co.uk” and “.co.jp” are TLDs also.

The browsers will not allow you to raise the domain of an HTML document to something more specific than its domain of origin, nor allow lateral domain shuttling.  Changing document.domain from “two.foo.com” to one.two.foo.com” is forbidden.  Changing a document.domain from ”one.foo.com” to “two.foo.com” is forbidden.

Irreversible (Mostly)

Firefox 1.5 and 2.0 will not allow you to assign a domain name that is more specific than the document’s current domain name under any circumstances.  Once you lower one.foo.com to foo.com, it’s stuck at foo.com forever.  The only way to clear that state is to reload the page.

IE6 and IE7 will allow you to raise a document’s domain back to it’s actual domain of origin.  If a page was served from one.foo.com, and you lower it to foo.com, IE will let you raise it back to one.foo.com.  However, I’ve seen some instabilities and inconsistencies in the aftermath of “raising shields”, so I don’t recommend relying on this behavior.  Since Firefox doesn’t allow restoring domains to their original values, you should ignore the fact that IE sort of does allow it.

Bridging Silos Via Least Common Denominators

When an HTML document’s domain is lowered to a parent domain, the security context and JavaScript symbol space of that document joins the security context and JavaScript symbol space of any and all pages that are also in the parent domain.  JavaScript in your page served from one.foo.com and lowered to foo.com can access JavaScript functions and variables defined in other pages whose domain is foo.com, and visa-versa.

So, if you have pages on one.foo.com that would like to interoperate with pages on two.foo.com, you can use domain lowering to pull down the domain barriers just enough to allow them to talk to each other, but still provide domain protections against third parties trying to steal or corrupt the internal state of your web app.  Place a JavaScript block at the top of each page in the “one” and “two” subdomains which assigns document.domain = “foo.com” and you’re good to go.  All the pages will operate as though they were served from the same domain, and can access anything in each other’s DOMs and JavaScript symbol space.

One or the Other, Not Both

Note that once your one.foo.com page has been lowered into the parent domain, your HTML and JavaScript code loses all access to DOMs and JavaScript data in any other pages that are still in the original one.foo.com subdomain.  A web page can only be in one domain context or the other, not both.

Interesting Inconsistencies

Domain lowering applies only to the DOM and JavaScript sandboxes.  Parts (actually, nearly all) of the browser execute in native machine code outside the browser security sandbox. Native objects exposed to JavaScript in the sandbox are largely on their own to implement appropriate security checks on operations initiated by JavaScript.  JavaScript can’t access the local file system, for example, but if the user installs an ActiveX control for IE or a browser plugin for Firefox that allows local file access, and that extension declares itself safe for scripting, then JavaScript could use that control to access files on the local file system.

In both IE and Firefox, XMLHttpRequest (XHR) is a native object exposed to JavaScript.  This is pretty obvious in IE6 since you have to construct the object using ActiveXObject; in Firefox you can deduce that the XHR is a native object from the phrasing of some error messages and error behaviors while the browser goes down in flames.

XHR is restricted to connecting only to the current HTML page’s domain of origin.  Domain lowering applies only to the browser sandbox.  XHR operates outside the browser sandbox, enforcing same-origin domain policy on its own. This leads to an interesting – and valuable – inconsistency:

XMLHttpRequest is not affected by domain lowering.

This means you can actually have one foot in each domain:  Your JavaScript executes in the context of the lowered subdomain (foo.com), but XHR requests made by your JavaScript are held to the domain restriction of the page’s original subdomain (one.foo.com). XHR doesn’t know anything about document.domain.

If you’re trying to get your JavaScript to open an XHR to a resource on foo.com, this can be infuriating because XHR won’t do it.  You have to refer to an HTML page served from foo.com in order to get XHR to open a connection to foo.com.

The Money Shot

This inconsistency in the handling of document.domain enforcement/awareness makes the following scenario possible:  The logic of your web app runs in the context of a page loaded from one.foo.com, and you want to XHR load data from two.foo.com.

Here’s how you do that:

1. Make your html page A served from one.foo.com lower its document.domain to foo.com
2. Place an html page B on two.foo.com, and have it lower its document.domain to foo.com early in its load cycle.  (A JavaScript statement in global scope in the <head> section is fine).
3. Implement a function GetData(callback) on this page that constructs an XHR request to load the desired data from two.foo.com.  Wire up the XHR onReadyStateChanged to process the data completion using a function implemented in B.html, and in that function pass the received data to the callback function passed into GetData().
4. Insert an invisible (1×1 pixel) iframe on page A and set its src to http://two.foo.com/B.html
5. After page A has fully loaded, and page B in the iframe has loaded, JavaScript code in page A can call the GetData() function in page B through the iframe element:  bframe.window.GetData(mycallback)

Believe it or not, this works. Domain lowering allows JavaScript to call between A and B, and the fact that B is served from two.foo.com allows the XHR request implemented in B to access two.foo.com.

Here Be Pixies.  (Try Not To Piss Them Off)

The path through this murky realm is neither straight nor wide.  If you take liberties or shortcuts with this recipe, be careful to test your code thoroughly on multiple browsers.  Chances are high that any deviation will lead to failure on one of the browsers.

IE is fairly flexible in this area.  You don’t actually have to implement the GetData function in the B page.  You can just construct in the A context an XHR object type from the B context and use it directly in the A context.  ( var xhr = new bframe.window.XMLHttpRequest() )  For IE, the B page need only lower the domain to foo.com.  After that, all the driving can be done from A.

Firefox is more particular about this technique.  Firefox will allow you to construct an instance of the B XHR in the context of A, but you’ll get access denied or weirder errors when you try to call the methods of the B XHR from the context of A.  Firefox gets confused when you call native object methods across these convoluted domain bridges, but calling JavaScript functions and methods works fine on either side of the context boundary.  Once the JavaScript call context gets from A to B, then the native object method calls will work.

This is also why step 3 above mandates that the XHR onReadyStateChange event handler should be wired to a function implemented in the B page – the native XHR object operating in the B context may have difficulty firing an event wired to a function in the A page context.

The Downside to Homogeneity

For domain lowering to work between two subdomains, both sides have to “lower their shields” to a common middle ground. As this technique catches on across departments and their corresponding subdomains, you can quickly reach a point where just about all the subdomains on the corporate web have provisions to lower their domain to the common corporate parent domain.

This is convenient and quite powerful for building web apps that can access data bits from all across the company.  The problem is that it weakens your corporate defenses across the board.  If just one of the subdomain silos were compromised and an attacker were able to inject malicious JavaScript to execute in the browser context of that compromised subdomain, that malicious code would have easy access to every subdomain across the company that lowers its domain to foo.com.

This risk grows with scale.  The more subdomains you have that routinely lower their domains to the common ground, the greater the risk that one of them may be compromisable and serve as a beachhead to your entire network.

Tune In Next Time

There is a way to mitigate this weakest link risk such that an attacker compromising a weak subdomain does not get access to everything.  This requires inverting some of the relationships presented in this article and making the silos deeper rather than shallower.  I’ll cover ”Siloed Domain Lowering” in my next cross-domain article.

Originally published on my MSDN blog.

Share/Bookmark