This seems to be also known as “link hash” (the URL portion that follows the hash character).

> After we have off-loaded our demo subdomain to a different port [...] But as it turns out, some browser don’t keep the fragment identifier across the redirect.

I’m not sure if this can be seen as a security feature: the port switching can be considered somehow aggressive… My guess (no testing performed!) is that keep the port while redirecting or redirect only to the HTTP standard port (80) may help working around the behavior.

Well, without trying to argument towards which would be the best approach (which, in this case, would likely be convincing my company to change a few IT policies, something I’ve been struggling with for a long time), I’d say best would be using port 80 on the machine which is serving the demos and dealing with the configuration on DNS level (mapping the “demo” sub-domain into the other IP). Of course I’m assuming the whole purpose of the changes was load balancing.

So what would be considered a fix in your world? Port 8000? 8080?

I have been behind “enterprise infrastructure” for many years, and without regrets as a good infrastructure included a proxy server that was able to make any connections to any external port, on behalf of the internal client.

Just bumped into the new port configuration… Many companies (such as my own) use a proxy-based access to access the Internet, many times locked to a set of well know ports. Your move just made me no longer being able to access the on-line demos using the enterprise infrastructure! :-p Please consider fixing it, as a quick visit to the (on-line) demos is a big helper (to check for new features, try to pin-point a regression to a particular version, etc.).

> So I’m more or less well again.

Glad to know you’re better, Martin!

I am in the process of setting up, gui testing at the moment.
Though I am using Delphi on a very large application, we have a Model/view structure with a centralised point of all gui execution comes out of 1 class (ApplicationGuiModel(AGM) ) via and all our windows are registered in Windowfactories. The other interesting thing is all my windows are address based and can be accessed accordingly (ie Employee\Employee notes\ ) as such when we write our gui testcases we simple access the AGM using addresses to get at the screens we want to. As we also have a comprehensive BusinessObject framework we test in the BO’s separately then inconjunction with our GUI’s we can populate BO’s or populate gui screens test what we feel like. So far it has come together quite well, better than expected.

If you have a good structured application (and adhere to rules laid out) testing those hard gui screens become a breeze.
cheers
Dave.