JavaScript doesn't have built-in functions to escape or unescape HTML, which may come in handy for certain DOM manipulations or AJAX scripting.  Here are the custom functions I wrote to handle these tasks.  I've tested the implementation with both IE and Firefox.

Setting the DefaultButton property on a form to an ImageButton, LinkButton, or Button with UseSubmitBehavior=false doesn't work on Firefox because the ASP.NET code hooking the Enter key on form submit looks for a "click" method on the button that Firefox does not support.

If you give your button a name attribute, say name='DefaultButton' for example, then throw the following JavaScript in a file that's included on all pages, it'll work.  The trick is to define the click method on Firefox's behalf.

Update on 6/9/08:

That fix apparently doesn't work completely, as when you hit <Enter> in a textarea the form is submitted.  That's a critical flaw.  I didn't want to wholesale replace ASP.NET's WebForm_FireDefaultButton method, but, c'mon, there's only so much tolerance anyone can have for hunting down and working around other people's bugs. 

So, here's a tweaked version of the function that fixes default button handling and works across browsers.  In order to use this patched function, you need to define it *after* all other JavaScript files and also after <ajaxToolkit:ToolkitScriptManager /> if you happen to be using it.

If you've done any dynamic manipulation of web pages, especially with AJAX or any other kind of web magic in the mix, you've run into IE's dreaded "Operation Aborted" error.

Here are some official comments on the issue:

• http://support.microsoft.com/kb/927917/en-us 
• http://blogs.msdn.com/ie/archive/2008/04/23/what-happened-to-operation-aborted.aspx

The blog post says that if you aren't meeting all 3 conditions, you're OK.  In my case, I believe I wasn't meeting the 3 conditions, and yet the problem persisted.  It was very hard to reproduce, too.  I had to have the offending website in the "Internet Zone" and experience some network lag to make it happen.

In the end, I found that if I replaced this line:

   document.body.appendChild(element);

With this one:

   document.body.insertAdjacentElement('afterBegin', element);

Everything worked fine.  Of course, this trick works only if you're inserting a node whose position isn't important, e.g. it's a div you're going to give an absolute position anyway.

Along the way I had tried wrapping the appendChild calls in a try/catch block, but unfortunatley the append would work fine, and then IE would complain with "Operation Aborted" only after the JavaScript finished.  I was hoping for a global exception handler to trap the problem, but fortunately insertAdjacentElement fixes the issue!

When using AJAX, an easy way to evaluate JavaScript or JSON returned from a web server is the good ol' eval function.  However, if an error is encountered during the evaluation Microsoft's Script Debugger doesn't let you see the offending line.  (I haven't checked what FireBug does yet.)

To get around this problem, you can insert the JavaScript as a <script> DOM node. 

In other words, instead of this:

try this:

With the latter approach, the debugger works great.

GWT doesn't yet emulate Java's Calendar class, so you're stuck writing your own code if you need to perform date manipulations, like rounding a date to the nearest month or truncating the time portion.  There are some gotchas here, like handling daylight savings time and leap years correctly, so the naive implementations of adding/subtracting milliseconds directly won't always work as expected.

Here's a class I wrote to help perform the date manipulations I need.  If you're using JavaScript directly instead of GWT, the port is straightforward. 

FusionCharts is using Adobe's ExternalInterface API to communicate between JavaScript and the SWF chart when you use FusionCharts.js to do things like setDataXML. For some reason, ExternalInterface isn't working correctly on IE under some conditions; the method simply doesn't exist on the OBJECT element.  I happen to be using the ExtJS library with GWT; either framework may be doing some DOM manipulations under the covers that are freaking out Adobe--but I haven't verified this.

A couple things to try:

1. Ensure that the ID and name attributes of the OBJECT and/or EMBED tags do not have characters such as . (period), -, +, *, /, and \.  Amusingly, this is because Adobe's ExternalInterface API is using a bunch of eval() JavaScript methods and these special characters get interpreted as JavaScript operators.  Yeah, great work, Adobe.
    
2. Hook up the ExternalInterface functions you need manually.  For example, here's the modified setDataXML function in FusionCharts.js to do the trick (code in red has been added):

Documentation on integrating with RoboHelp is sparse.  Here are some things I discovered by reading the JavaScript source (which looks like Win32 UI code out of the 1990s):

To link directly to a topic for context-sensitive help:

index.html#page.name.htm

To show the Index pane:

index.html#>>pdb=ndx

To show the Search pane:

index.html#>>pdb=nls

To show the Glossary pane:

index.html#>>pdb=gls

With these links, you can create a Help menu in your application with links to all of the appropriate pages:

If you have the patience, you can tweak the RoboHelp source to provide some pretty cool value-adds.  For example, I was able to add keyword search highlighting:

Can you spot the bug in the following function--designed to get the absolute position of an element on a webpage?

Here's a hint:  under normal operation it works fine. 

Here's another hint:  it involves IE "expressions."

So, what's the problem?  It comes down to this line of code:

Here curleft is defined as a local variable, but curtop is not!  curtop is actually synonymous with this.curtop, so it's a property of this, not a local variable.  Imagine what would happen if getLocation() were called recursively; the nested call would essentially change the value of curtop before returning, the outer function would return a bogus "top" value.  But there's no recursive call so there's no problem, right?  In my case, wrong!  Apparently as you access offsetLeft and offsetTop properties, IE may decide to evaluate expressions.  And if you've so happened to define an expression that calls getLocation(), you're suddenly making a non-obvious recursive call.  For example:  <div style='top:expression:getLocation(document.all.element)'></div> will trigger the bug.

The fix is to declare the variables this way instead:

I recently decided to hook document.onmousemove and document.onkeypress for idle detection on a web page.  Kind of the right idea, but surprising results. 

Did you know that, at least with IE 7, the onmousemove event continues to fire a couple times per second even when the mouse is not moving?  and even when the browser window doesn't have the focus, so long as the mouse is over the document?  Bizarre. 

There's an easy enough way around this issue: