Mozilla hispano, tu comunidad en español de Mozilla

Como ya muchos sabrán, la versión beta 1 de Firefox 4 fue lanzada hace unas semanas. La beta 2 seguirá muy pronto, y la versión final se espera a finales de este año.

Este período más o menos largo de transición es muy bueno para desarrolladores de complementos, porque nos da suficiente tiempo para actualizarlos y probarlos en Firefox 4. Por otro lado, esta nueva versión incluye una cantidad significativa de nuevas funciones y va a romper muchas cosas que los desarrolladores usamos, así que no va a ser sencillo actualizar los complementos para ser compatibles. Este es seguramente el primero de múltiples artículos que voy a escribir sobre la compatibilidad con el Firefox 4.

(Este artículo es una traducción directa del que hice en el blog oficial de complementos. Los enlaces son a documentos en inglés porque no hay equivalentes en español.)

Primero que nada, el MDC es nuestro amigo: Firefox 4 para desarrolladores. Este es el documento que deberá tener toda la información necesaria para desarrolladores web y desarrolladores de complementos sobre Firefox 4. Asegúrense de visitar este documento regularmente y buscar cambios que hayan ocurrido. Si hay algo que falte en ese documento, por favor agréguenlos ustedes mismos, o contáctenme a mí (jorge arroba mozilla punto com).

Estos son algunos de los puntos más importantes de este documento.

El nuevo objeto para administrar complementos

La interfaz nsIExtensionManager ha sido eliminada, junto con su sistema de almacenamiento en RDF. La información de complementos instalados ahora está guardada en una base de datos SQLite, y el administrador de complementos es ahora un módulo JS llamado AddonManager.

Una diferencia clave en esta nueva interfaz es que obtener datos de complementos ahora es asíncrono. Esto aplica también al acceso por medo de la librería FUEL, así que todos los complementos que hagan acceso de datos de complementos son afectados. Esto es particularmente delicado para complementos que tienen que obtener y lidiar con esta información durante el proceso de arranque de Firefox. Sin embargo, si también están tratando de seguir las recomendaciones para mejorar el desempeño en el arranque, ya deberían estar planeando tener un proceso de inicio que sea asíncrono.

Registro de XPCOM

Hay mucho ocurriendo en esta área: cambios de XPCOM en Gecko 2.0. Ningún componente va a funcionar en Firefox 4 a menos que se hagan los cambios detallados en ese documento.

Los componentes ahora se tienen que declarar explícitamente en el archivo chrome.manifest. Algunas notificaciones de observers en el arranque también se han eliminado, dejando solamente la que ha sido recomendada por algún tiempo: profile-after-change. Los registros de categorías y los observers también tienen que ser declarados en el manifest, y debido a esto algunos nombres de categorías han sido cambiados.

Cambios al tabbrowser

Los eventos TabClose, TabSelect y TabOpen ya no se propagan hasta el elemento tabbrowser, también conocido como gBrowser. Los manejadores para estos eventos se deben agregar a gBrowser.tabContainer.

El XUL remoto será eliminado

El XUL remoto es una función raramente usada de los navegadores basados en Gecko, la cual permite crear sitios web usando XUL en vez de HTML. Como XUL es solo soportado por algunos navegadores, nunca tuvo mucho sentido crear sitios con él. Sin embardo, el XUL ha sido utilizado exitosamente en un número reducido de aplicaciones internas de negocio (también conocidas como “materia oscura”).

El XUL remoto ha sido un gran problema de mantenimiento, y ha sido la fuente de muchos problemas (bugs) y problemas de seguridad. Por esto, el XUL remoto será eliminado en el Firefox 4. Por suerte el HTML5 y nuevo soporte de CSS incluyen un modelo de cajas (box model) bastante robusto, así que la mayor pérdida para desarrolladores web es que no van a poder usar XBL. Si se preguntan qué sucedió con el XBL 2, eliminar el XUL remoto es un paso necesario para implementarlo.

Cambios de tema e interfaz gráfica

Esta es un área donde tienen que regresar a revisar el progreso con frecuencia, porque hay planes muy ambiciosos para la interfaz gráfica del Firefox 4. Dependerá del tiempo y las soluciones a problemas complejos y si se logran implementar o no todos los cambios planeados.

El principal documento sobre estos cambios está en el wiki de Mozilla: prioridades para Firefox 3.7. Estos son algunos cambios importantes que deben conocer:

• Pestañas (tabs) en la parte superior. Habrá una preferencia que controla la ubicación de las pestañas y las barras de herramientas.
• Menú de aplicación. En Windows (por lo menos Vista y Windows 7), habrá un solo botón de menú en vez de la barra de menú completa. El menú “clásico” se activa o desactiva presionando la tecla Alt. Esto seguramente va a tener un impacto en los complementos que agreguen elementos al menú principal.
• Pestaña de inicio. Ésta es una pestaña situada en una posición fija al inicio de las pestañas.
• Pestañas de aplicación. Va a ser posible convertir cualquier pestaña en una pestaña de aplicación, lo cual significa que no pueden cerrarse fácilmente y tienen sus títulos ocultos, solamente mostrando el ícono. Hay cambios más interesantes siendo planeados, como esconder las barras de herramientas en estos casos.
• Hay discusiones sobre eliminar la barra de estado por completo, otro cambio importante para desarrolladores. La discusión se ha extendido por varios artículos, y seguramente continuará. Para más información leer las partes 1, 2 y 3.

Más cosas

• Por razones de desempeño, Firefox 4 ahora hace caché de algunos recursos más agresivamente, incluyendo el chrome y archivos JavaScript de los complementos. Esto puede producir comportamientos inesperados durante el desarrollo de un complemento porque los cambios en algunos archivos pueden no aplicarse a menos que se borren los archivos de caché correspondientes. Éste es el bug al respecto. Por favor no comenten en él sólo por apoyar alguna solución; ya hay mucho de eso ahí.  En resumen, los desarrolladores se tienen que asegurar que tienen las preferencias configuradas adecuadamente y que usan la opción -purgecaches al ejecutar el perfil de pruebas. Esto todavía no cubre el caso de los módulos JS, pero será corregido en el futuro.
• Los identificadores de User Agent van a ser minimizados por varias razones. Para alinearnos con ese esfuerzo, los editores de AMO vamos a empezar a buscar cualquier manipulación de estos identificadores en los complementos. Vamos a prohibir cualquier modificación innecesaria de ellos.
• Un programador me informó que hacer drop de un URL en la barra lateral ahora tiene un comportamiento por defecto de intentar abrir el URL. Si manejan drag and drop en una barra lateral, asegúrense de usar preventDefault.

Como pueden ver, hay mucho trabajo por hacer para adquirir compatibilidad con Firefox 4, así que este es un buen momento para empezar. Tengan en mente que Firefox 4 todavía está cambiando mucho, y que hay muchos más cambios en camino. No crean que se puede crear una versión final de su complemento sólo haciendo pruebas con las primeros beta. Mi recomendación es que se tomen su tiempo y se aseguren de estar al tanto de noticias y cambios en el Firefox 4.

Y, claro, hay muchas cosas geniales que se están agregando a Firefox 4 que van a permitir nuevas funciones en los complementos, incluyendo animación 2D y 3D, multi-threading e interacción directa con librerías del sistema operativo. Firefox 4 para desarrolladores es su amigo . El blog de hacks también tiene una buena cobertura de esto.