Descobri um problema irritante com o IE7/8, e a sua implementação de AJAX.
Basicamente, se usarem JQuery, para fazer pedidos ao servidor, estes são feitos, usando o charset "UTF-8", e está documentado. Funciona correctamente se usarmos browsers considerados "normais", como: Firefox, Chrome, etc... mas no caso do IE não podia ser assim não é verdade ...
No caso do IE7, o pedido vai para o servidor e leva o "header" ("Content-Type:") correctamente definido, mas o IE7, simplesmente não faz a conversão dos dados para o formato correcto.
Para funcionar em IE7/8, é necessário forçar o contentType na chamada ajax do JQuery, semelhante a isto:

$("form#myForm").ajaxForm(
 {
  contentType: 'application/x-www-form-urlencoded; charset=UTF-8',
  success:
   function( data )
   {
    alert( 'success' );
   }
 } );

WebGl no Firefox

Como ativar o WebGl no Firefox. Os passos são simples:

1. Aceder a "about:config" na barra de endereços
2. pesquisar por "webgl", na página "about:config"
3. alterar ou verificar que as seguintes configurações estão a "false"
   • webgl.disabled
4. alterar ou verificar que as seguintes configurações para "true"
   • webgl.force-enabled
   • webgl.force-layers-readback (algumas aplicações precisam deste setting)
   • webgl.prefer-native-gl (optimização)

NOTA: Para alterar uma configuração basta fazer double click. Algumas aplicações para testar se o WebGl está ativo e a funcionar.

• Official WebGL Test Page
• Quake 3 - Level
• Toy Car demo
• Large collection of demos using threejs.

Hoje após duas horas desesperantes, descobri a solução para o problema do scrollTop no IE8, quando é usado dentro de um 'SELECT'.

Basicamente, no IE8 quando se adiciona um elemento 'OPTION', via Javascript a um 'SELECT' que seja do tipo 'multiple' (nota: estou a usar um 'size' de 10), não posiciona a scroll bar, de forma a mostrar o elemento 'OPTION' que foi inserido (já pré-selecionado).

Isto tem o inconveniente de o utilizador não se aperceber que o elemento foi realmente adicionado, se a combo não estiver na posição ideal.

Note-se que estou a inserir os elementos ordenados alfabeticamente, logo a inserção poderá ocorrer em qualquer posição, dependendo dos elementos já existentes e do elemento inserido.

Para corrigir este problema de usabilidade, defini o seguinte código após ter efectuado a inserção no 'SELECT', dentro de um objecto JS que o contém:

   // we have to do this, in order for IE8 to correctly scroll to the added element
   if( option.selected)
   {
      var topScroll = 0;
      if( this.select.length )
         topScroll = index * (this.select.scrollHeight / this.select.length );

      this.select.scrollTop = topScroll; // <=- linha problemática
   }

No entanto, após fazer debug da coisa, a 'linha problemática' aparentemente não executa !!!
Isto é, mesmo que o valor topScroll seja diferente de zero, o campo 'this.select.scrollTop' fica intocado.
É como se a instrução nunca tivesse sido executada !!!

Após perder umas centenas de neurónios, reparei que se eu forçar o valor no debugger a correcção funcionava !

Após mais algumas tentativas, para perceber o problema, cheguei ao momento Eureka!

O IE8, pega de empurrão!

Isto é a solução é insistir à canzana ! :)
Ou seja, repetir a instrução de atribuição !

   // we have to do this, in order for IE8 to correctly scroll to the added element
   if( option.selected)
   {
      var topScroll = 0;
      if( this.select.length )
         topScroll = index * (this.select.scrollHeight / this.select.length );

      this.select.scrollTop = topScroll;
      this.select.scrollTop = topScroll; // WE MUST DUPLICATE THIS LINE, due to an IE8 Bug !
   }

Incrível, mas é verdade ! E assim já funciona como esperado e é inócuo para os outros browsers, como seria de esperar.

Java decompiler para o Eclipse

O Eclipse Java Decompiler pode dar jeito, quando ao meio do debug, nos deparamos com uma classe de uma lib (jar) qualquer, da qual não temos a source disponível.
Permite fazer o decompile da class enquanto fazemos debug, para determinar a fonte do problema.

IE8 Document Mode é Sticky !

Mais uma "feature" do IE8!
Se tivermos uma página simples, que abrimos em dois tabs, mas no primeiro tab definimos o URL como 'localhost' e o outro tab com o URL com o nome da máquina propriamente dito ("wheat", no exemplo).

Vamos constatar que o IE8, vai fazer o 'render' da página com margin e offset distintos, para a tag BODY.

A página está definida com o seguinte DOCTYPE:
<!-- DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" -->

Após mais alguns testes, acabei por descobrir que o problema não era do URL, mas sim devido ao facto de ter reutilizado um tab (alterando o seu URL), que conteve anteriormente uma página que forçou o modo de compatibilidade 'IE7' no IE8, com o seguinte meta dado no head !

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

Resumindo e concluindo, o modo de compatibilidade aparentemente é uma propriedade do tab, e que não muda com a alteração do endereço (URL), como devia.

Isto implica que uma página que faça um render correcto, seguindo os standards, pode ficar completamente desfigurada no IE, se o tab tiver sido usado para aceder a outra página previamente, que tenha forçado o modo de compatibilidade do IE.

IE8 não gera evento form submit, em certas condições

Ultimamente, tenho andado a dançar o fandango com o IE8, ao fazer um 'port' de uma aplicação IE6 para IE8.

Infelizmente os bugs são mais que muitos: James Hopkins IE8 Bugs e Gérald Talbot's IE8 Bugs chegam para ter uma ideia dos problemas que se tem pela frente, já para não falar nos modos de (in)compatibilidade, que o bicho trás para o IE7.
Estranho é que alguns anos após o lançamento do IE8, a grande maioria dos problemas continua por resolver.

Mas voltando ao que interessa, o IE8 tem outro BUG ainda não documentado que consiste na falha em gerar um evento de 'submit' num form, em certas condições.

Se tivermos o seguinte código, o IE8 gera o evento 'submit' correctamente:

<form action="login">
 <label for="user">User</label>
 <input id="user" name="user" type="text" value="" />
 <br/>
 <label for="pass">Pass</label>
 <input id="pass" name="pass" type="password" value="" />
 <br/>
 <input type="submit" value="Submit" />
</form>

Mas se quisermos adicionar um botão adicional, para por exemplo limpar o form (exemplo simplificado), o evento já não é despoletado.
NOTA: A implementação da funcionalidade em 'javascript' não é mostrada.

<form action="login">
 <label for="user">User</label>
 <input id="user" name="user" type="text" value="" />
 <br/>
 <label for="pass">Pass</label>
 <input id="pass" name="pass" type="password" value="" />
 <br/>
 <input id="iClear" type="button" value="limpar" />
 <input id="iSubmit" type="submit" value="Submit" />
</form>

E isto acontece apenas e somente, porque o IE8 não gosta que exista nenhum INPUT do tipo 'button', antes de um INPUT do tipo 'submit'. Isto é. aparentemente o IE8 procura o primeiro botão disponível e activa-o, mas se não fôr um botão do tipo 'submit', o form não é submetido, pois activa o botão errado.

A solução passa por ter o INPUT com o type='submit' aparecer em primeiro lugar no HTML.

<form action="login">
 <label for="user">User</label>
 <input id="user" name="user" type="text" value="" />
 <br/>
 <label for="pass">Pass</label>
 <input id="pass" name="pass" type="password" value="" />
 <br/>
 <input id="iSubmit" type="submit" value="Submit" />
 <input id="iClear" type="button" value="limpar" />
</form>

Se não gostarem do botão à esquerda, até por questões de usabilidade, podem sempre posicionar os botões por css com um float:right, que na pratica vos inverte a ordem relativamente a existente no HTML.

Tabela com múltiplos THEAD versus TBODY (IE Quirk)

Caso se crie uma table com mais do que um thead, algo deste género:

<table id="myTable" cellspacing="0px">
 <thead>
  <tr>
   <th colspan="7">Outubro</th>
  </tr>
  <tr>
   <th>Domingo</th>
   <th>2ª-Feira</th>
   <th>3ª-Feira</th>
   <th>4ª-Feira</th>
   <th>5ª-Feira</th>
   <th>6ª-Feira</th>
   <th>Sábado</th>
  </tr>
 </thead>
 <thead class="days">
  <tr>
   <th>4</th>
   <th>5</th>
   <th>6</th>
   <th>7</th>
   <th>8</th>
   <th>9</th>
   <th>10</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>TESTE</td>
    ...
  </tr>
  ...
 </tbody>
 <tfoot>
  ...
 </tfoot>
</table>

Tudo funciona perfeitamente (em FF3.0.14 ou no IE6.02900), inclusive aplicar CSS específico ao thead cuja class="days".

Mas se tentarem aceder por javascript ao array the objectos tBodies da tabela, as coisas ai mudam de figura.

var myTable = document.getElementById( 'myTable' );

var rows = myTable.tBodies[0].rows;

alert( 'Dados da primeira coluna do body = ' + rows[0].cells[0].innerHTML );

No caso do FF, retorna exactamente o esperado "TESTE", no entanto, no caso do IE vai retornar "4" ou seja, o conteúdo da primeira coluna do segundo thead.

Isto acontece porque o IE, erradamente associa o segundo thead (days), como se fosse o primeiro tbody, o que claramente não é, inclusivamente é incoerente com a aplicação de estilos, que essa sim funciona correctamente.

A solução para o problema, passa por fugir dele :) isto é, evitar o uso do thead adicional, e aplicar o estilo (class) directamente no tr. Não esquecer de actualizar o CSS de forma a corresponder com a alteração efectuada.

<table id="myTable" cellspacing="0px">
 <thead>
  <tr>
   <th colspan="7">Outubro</th>
  </tr>
  <tr>
   <th>Domingo</th>
   <th>2ª-Feira</th>
   <th>3ª-Feira</th>
   <th>4ª-Feira</th>
   <th>5ª-Feira</th>
   <th>6ª-Feira</th>
   <th>Sábado</th>
  </tr>
  <tr class="days">
   <th>4</th>
   <th>5</th>
   <th>6</th>
   <th>7</th>
   <th>8</th>
   <th>9</th>
   <th>10</th>
  </tr>
 </thead>
  ...
</table>