We do all of our work on a publicly available dev server with the search engines blocked, meaning that it’s easy to update our clients on our progress and it doesn’t tie us to a single machine.

You need to understand how broswerlab works in order to see why it justifies being a hosted service: the screenshots that you get are actually taken by a load of virtual machines which when triggered open the page in their browsers (thus, the page is rendered natively on win/mac and in the specific broswer), take the screenshots and send jpegs back to the browser lab server, which then serves it in the window.

If they could build a desktop application, it would have to work as a web server for the time of the screenshot taking, which opens your computer up to a load of security issues, devours a load of resources and raises a load of proxy issues, where certain certain closed ports would block the access, thus making the whole thing completely useless.

it seems — in order to test a website using BrowserLab — the website or page has to be published in public place (not intranet, not password protected) in order for the BrowserLab product to run its comparative screenshot tests. also, it doesnt seem like website flows which require a sessionID in the URL (like a shopping cart type “buy flow” within a website) can be easily tested and compared.

have you found this to be the case as well; or … am i missing something?

i loved the idea of a virtual BrowserLab … but when it came right down to using it, practically, i couldnt quite love the implementation.

i wish Adobe had a version i could install within my network (an BrowserLab appliance?), so i wouldnt have to publish pages which may not be production ready. and i also wish it had a method of following a session through several pages.

thanks for your post.

cheers.