Lukav's Weblog

There is a very interesting service out there:

http://browsershots.org/

It makes a screenshot of a page with various browsers like: Dillo 0.8, Epiphany 2.14, Epiphany 2.16, Firebird 0.6, Firebird 0.7, Firefox 1.0, Firefox 1.5, Firefox 2.0, Firefox 3.0, Flock 0.7, Galeon 2.0, Iceweasel 2.0, Konqueror 3.5, Mozilla 1.0, Mozilla 1.1, Mozilla 1.2, Mozilla 1.3, Mozilla 1.4, Mozilla 1.5, Mozilla 1.6, Mozilla 1.7, Navigator 4.8, Opera 9.2, Opera 9.10, Phoenix 0.1, Phoenix 0.2, Phoenix 0.3, Phoenix 0.4, Phoenix 0.5, SeaMonkey 1.0, SeaMonkey 1.1, Windows MSIE 5.0, MSIE 5.5, MSIE 6.0, MSIE 7.0.

Great idea and a vary usefull one.

I’ve test it with my blog you can have a look here:http://browsershots.org/website/http://lukav.com/wordpress/

Hi, I’ve been using a Virtual machine for some time now to test with IE6 (Microsoft Internet Explorer) and IE7. However this machine was taking valuable resources just to have IE6 running, which was very inefficient. So I’ve look for another solution and found it.

http://tredosoft.com/Multiple_IE

Thank you. THANK you vary VARY much. TredoSoft.

They made an installer that installs IE versions: 3.0, 4.01, 5.01, 5.5 and 6.0 (by the time of this writing) on a single PC as a standalone app.

So far it works like a charm.

For those of you that have discovered that when you have Firebug installed and are developing some synchronous XMLHttpRequest everything works, and when you disable it it stops: here is the problem.

Believe it or not it is a bug in Firefox NOT in Firebug. It turns out that Firefox doesn’t call onreadystatechange when the you set the 3 parameter (async) to false in open. Probably FF expects that when a call is synchronous the developer will process the result in the lines following the send call. May be this make sense, but if you want to quickly test async/sync calls or use a library that doesn’t take care of this, you be in trouble.

I can say for certain (I’ve committed the code myself) that the next release of OpenLink AJAX Toolkit won’t have this problem and will make no difference if you have Firebug or not.

I use the following to catch the situation where Firebug is not installed or is installed but disabled:

if (OAT.Browser.isGecko)
{
  try {
    if (!xhr.options.async && xhr.obj.onreadystatechange == null) {
      OAT.AJAX.response(xhr);
    }
  } catch (e) {
    if ((e.message && e.message == 'Permission denied to create wrapper for object of class UnnamedClass') ||
         e == 'Permission denied to create wrapper for object of class UnnamedClass')
      OAT.AJAX.response(xhr);
 }
}

OAT.Dom.isGecko() – return true if it mozilla and derivatives
OAT.AJAX.response – is the function that is normally called when the request finish.
xhr.options.async – is holding if the call is async or not
xhr.obj.onreadystatechange – is the original Firefox XMLHttpRequest object instance, since the code above works in the context of OAT

Today I had to make an AJAX application iSPARQL compatible with Microsoft Internet Explorer, at same point we decided to not support it, but now we realized that some small part of it can be supported. We don’t supported because IE doesn’t support embedded SVG… Anyway…

I’ve spend several hours trying to catch some errors of the sort: “object expected” or “object doesn’t support this method or property”. Have you seen those? Yes, the once that doesn’t give a clue which is the object and the lines usually has nothing to do with the reality. So finally I’ve decided to find a JS debugger that would tell me at least where the problem is. I didn’t have much hope, because I’ve spend time to search before and didn’t find anything to my taste that did the job, until I found this: MSE – Microsoft Script Editor

Thank you Erik for the wonderfull post.

It turns out Microsoft has a debug for their free browser in their payed Office package. Funny isn’t it. It turns out that developers that want to easy their life when writing JS for IE has to purchase at least MS Office.

It is not perfect, or even good, but it is the best I have seam so far and at least you get to actually see the row where the error occured or even execute step by step.

Anyway here is what Erik have posted (on my installation – Office 2003 Professional the exe was called MSE7.EXE):

MSE – Microsoft Script Editor

Microsoft Script Editor is probably one of the lesser known tools that can really make a difference when it comes to developing web applications. MSE is a debugger, much like Visual Studio and it comes bundled with Microsoft Office. It should not be mistaken for Microsoft Script Debugger which is a piece of crap compared to MSE. MSE got all the nice features Visual Studio has without the bloat.

MSE is installed at %ProgramFiles%/Microsoft Office/OFFICE11/MSE7.exe. Older versions might be installed at a slightly different location and if you cannot find it just search for mse. If you still cannot find it and you have an old Microsoft Office CD lying around you can install it from there. If you select custom install or add remove components it should be located under Microsoft Office / Office Tools / HTML Tools /Web Scripting / Web Debugging.

By default script debugging is disabled in IE but you can enable it by
unchecking Tools / Internet Options... / Advanced / Disable script
debugging (Internet Explorer).

So how do you use this mysterious tool? MSE allows you to debug exisiting IE processes but more importantly it is triggered by the debugger statement (which by the way also works if you have Venkman opened for Mozilla). If you already have IE up and running or you can’t edit the source files of the web application you can get into the debug mode by opening the Debug / Processes dialog and from there select the process to attach to.

Once in debugg mode you can step through the program to see what is going on. Out of the box not much is shown but things like local variables, watch, running documents, call stack and more is available to you under Debug / Window.