Protocol optimized

After some tinkering with the old protocol, Felipe and I thought it was over sized and a little repetitive to work with, so we put it on a diet. Now it's more compact and kind of easier to work with, I'll show you/

This would be a sample file written with the new version:

{
  "frames":[
     {
       "positions":[
            {"id":"1","x":300,"y":300}
        ],
       "events":[
           {"id":"1","type":"MozTouchDown"}
       ]
     },
     {
       "active_duration": 5
     },
     {
       "positions":[
           {"id":"1","x":400,"y":400}
       ],
       "events":[
          {"id":"1","type":"MozTouchRelease"}
       ]
     }
  ],
  "fps": 10
}

The new rules are even simpler:

• frames
  A collection of Frame-Objects
• Frame-Object
  An object that has two properties to define the status of each frame:
  • positions
    A collection of objects containing the finger ID that the position belongs and x and y position: {ID, X_POS, Y_POS}
  • events
    Collection of objects containing finger ID and Event Type. Event Types are to be designed, but inital ones are the same as the implementation:
    • MozTouchDown
    • MozTouchUp
    • MozTouchRelease
    • MozTouchMove
• Frame-Object Types
  There are three Frame-Object types now:
  • Snapshot
    This is the type in where you define positions and events
  • Spacer Active
    A Frame-Object is of this kind when it's only property is "active-duration". This indicates that between two snapshots objects an animation should be done, and the duration is the value of "activ-duration"
  • Spacer Inactive
    This has the same structure as the active one, but instead the property is "idle-duration". This indicates that no transition should be calculated between two snapshots, it's a waiting time.
• fps
  The framerate that will be used to play the file

Changes:

• Frame-objects no longer have a fingers collection. This is now deduced from the positions IDs
• Events now are the same as the ones implemented in firefox. This is to simplify naming, and probably they'll soon change to something more "human" and less "techy".
• The Frame-Objects have 3 subtypes now: Snapshot, Spacer Active, Spacer Idle.

Demo Available

As I promised last time, the code is ready for some demoing!

As the multitouch part is not yet available on firefox latest builds you'll have to use a special build of firefox to try this stuff. Here you'll find a compiled version for your system:

• Mac OSX (tested on 10.6, should also work on 10.5)
• Windows
• Linux (not here yet, still have to compile this)

Now that you have the correct build to test the extension is time to install it. I would strongly recommend you to create a new profile, it's a good practice when you're trying new stuff that may explode .

You can grab here the extension compiled as an XPI, and here some good sutff: you won't need to restart firefox to try it out! As a side-effect of coding the extension with Jetpack, and having to use the latest firefox build for the multitouch part, we end up having the best setup ever: restartless addons enabled! To install the addon, just download it and drag-n-drop it on firefox.

But we need some demos to try the addon, so here you have a list of available demos to try multitouch coded by Felipe Gomes:

• Image Crop
  Draw a rectangle to potentially "crop" an image with a pinch gesture
• Image Resize
  Shrink and Enlarge images with pinch gestures. With two simultaneous pinches you can resize two different images
• Marcio Drawing
  A demo that lets you draw with your fingers. Touching a color in the pallete, changes the drawing color.
• Pong (not much usefull in for this addon)
  A simple implementation of the classic Pong game.
• Touch Canvas
  Simple canvas that tracks your fingers
• Tracking Divs
  Two divs keep tracking of the fingers you have on the screen
• Fluids
  Fluid simulation following your fingers!

And here are some sample input files:

• Sample 1: A simple pinch gesture.
• Sample 2: Two simultaneous simple pinch gestures.
• Sample 3: Cross-drawing (this is designed for the Marcio Drawing Demo)

Using the simulator is pretty simple, it just has three buttons:

The first one lets you load an input file (as the samples I'm providing) to be processed. The second one opens a kind of "console" so you can write a input file on the fly and then run it with the third button, as you can see here:

Where to go now

The next steps I think will be the harder ones. What is pending to be added is a way to simulate multitouch input with just one pointer. That means, how to make the extension itself write the input files instead of doing it by hand. I still have to come up with a UI for that, and any suggestion/idea is welcome. If you think you can collaborate on that stuff, don't hesitate to contact me on twitter or leaving a comment.

Feedback

I would really appreciate if some (or all!) of you try this extension and reports issues/enhancements (you can do it here), that would be priceless. Of course any thing you want to ask you can reach me in #jetpack on irc.mozilla.org,  I go by the name of "peregrino", or by leaving a comment here.

As some of you may know by my twitter time-line, I've been accepted into the Google Summer of Code 2010 (GSoC) to develop a project for the Mozilla Foundation. The GSoC is a program in which Google funds students from all around the world to work on a project for an Open Source Organization in their Summer free time. In my case -and the same is for the ones who live in the Southern Hemisphere- is the Winter of Code, but is fun all the same!

My project is a Multitouch Simulation Framework for Firefox. As the name tells, the idea is to make an extension that lets you simulate multitouch input form firefox to test your web aplication. This will be cool, as it will let developers do multitouch interactions without actually having to own a multitouch device!

Initial Considerations

The idea is that you can write (and maybe later, record) a sequence of multitouch steps like:

Drag finger1 from (100x, 100y) to (150x, 100y)
Double-tap (150x, 100y)
Pinch Zoom 30px centered in (75x, 30y)

so one of the first issues I faced with this project was actually writing a protocol that let you do that. The first idea that came to my head was that the TUIO protocol would be a wonderful source of inspiration, with loads of useful info... Now I know it was a really naive thought.

The TUIO (Table-Top User Interfaces Objects) project has a protocol for sending multitouch events through a network, something very similar to what I needed. So I read all the protocol versions (1.0, 1.1 and 2.0) to understand it fully, and just came to the conclusion that the TUIO protocol was to me like a bazooka to kill a mosquito. It defines things in a much more deeper detail that the one I need, is a lot more generic -I just need to track fingers, TUIO is able to track even custom shapes in 3D- and has nothing about timings. So... no soup for you, come back one year!

So if I couldn't get anything from TUIO I had to write it all by myself, those were good and bad news. Good because I could make the spec so that the final files were written in JSON -something way more JavaScript friendly!- and bad because I couldn't take advantage from TUIO.

After a while thinking, I came up with what I think can be called the 0.1 version of my protocol.  My idea is to do various iterations of the protocol while I implement the extension, that way I can tweak what I think is being troublesome to use, or implement suggestions. The most complicated thing I faced with my protocol is the timings and frame-rate.

Timings and Frame-Rate

The aim of this project is to replay actions, so the protocol should be focused on replaying more than mere message passing (as TUIO is) so timings are important. I don't know if it's the best decision, but I decided to put a global frame-rate property and to writean object defining each frame.

Taking something from TUIO the addition and deletion of fingers is not explicitly told, is deduced from the difference with the previous frame's active fingers. Having "frame-objects' can be a bit redundant sometimes, but is the most simple approach to a protocol to describe things for later replay: being explicit. Is like MPEG-1 and WebM, the former is heavier but simpler to read than the later optimized format.

Having a constant frame-rate makes easier to implement in the extension, so thas was the way to go. Although in some points it might make sense being able to temporarily reduce the framerate, or indicate that some frame-object spans for more than one frame, those are power-features that can be later considered.

Velocity

Other thing I had to consider was the velocity and acceleration of the finger movements. You may notice that when you move your mouse, or your finger on the trackpad, you don't make constant velocity movents. Usually you accelerate and then slow down to be more precise, doing the complete movement with constant velocity would seem like it was done by a robot... But this is hard to describe in a protocol, and when acceleration comes in timings are harder to implement, so the decision was to make all the movements with constant velocity first. In a later iteration accelerations could be implemented.

The Protocol

This would be a sample file written with this protocol:

{
    "frames":[
    {
        "fingers":['1','2','3'],
        "positions":[
            {'1',0,0},
            {'2',10,10},
            {'3',20,20}
        ],
        "events":[
            {'1', 'DOUBLE_TAP'}
        ]
    }
    ],
    "fps":20
}

The rules are simple:

• frames
  A collection of Frame-Objects
• Frame-Object
  An object that has three properties to define the status of each frame:
  • fingers
    This is a collection of IDs to identify each finger. The IDs are strings
  • positions
    A collection of objects containing the finger ID that the position belongs and x and y position: {ID, X_POS, Y_POS}
  • events
    Collection of objects containing finger ID and Event Type. Event Types are to be designed, but inital ones are: TAP, DOUBLE_TAP, TAP_DOWN, TAP_UP
• fps
  The framerate that will be used to play the file

Possible Issues

Some issues may arise from the current protocol version, this are the ones I could think of

• If a user wants to have multiple fingers fixed and just a few moving, he has to copy several times the same info for the still fingers. This could be reduced, maybe
• To code pauses between movements, the final frame-object has to be copied fps x seconds times...
• Movements more complicated than just moving between two points in a straight line can be somewhat complicated to code manually...

Well, that's all that I have for now, next post will hopefully have some piece of code to actually try the extension and a discussion about my progress with coding it in Jetpack.

Please, share your thoughts in the comments!

Hernán

Lo primero que hice cuando me enteré de la noticia fue correr al App Store a descargarla, pero recién a eso de la 1am y usando algunos proxies logre que el App Store me la dejara instalar. Por suerte ahora ya debería estar disponible para descargar sin ningún problema.

Después de probar al Opera Mini durante unas horas, tengo algunos comentarios al respecto.

Para todos los que tenían la intriga, no, no tiene soporte para Flash. Eso no es ninguna novedad, y no esperemos que haya siquiera un rastro de Flash en el iPhone dada la posición actual de Apple y la famosa 3.3.1
La velocidad del navegador es realmente impresionante, ahí hay que sacarse el sombrero. Puede ser que sea debido a que el Mini tiene su propia técnica de trasmitir imágenes, pero es más veloz que Safari.
El scrolling es bastante bueno, al igual que el zooming, pero creo que aquí el Safari es mejor. El scroll del Safari es un poco más fluido, y la falta de Pinch-Zoom en el Mini se nota bastante para alguien acostumbrado a Safari.
Los features extra que tiene como el speed dial y la opción full-screen están muy buenos y son cómodos. Lo que no es tan cómodo quizás es el manejo de los tabs, por más que no tenga el limite de ellos que tiene el Safari. Cuesta un poco navegar entre tabs sin cambiar a uno por accidente
Otro punto a favor es la variedad de opciones para setear, es mucho mas customizable que el Safari, aunque no tenga soporte para los Opera Widgets.
El render de las páginas tampoco destaca por su excelencia, hay muchas webs medio rotas en el motor del opera, por más que sea muy rápido.

Ahora que estoy llegando al final, tengo la queja mas importante a la experiencia de usuario. Al ser el opera mini un navegador multidispositivo, generalmente usado en celulares o smartphones de menor capacidad que el iPhone/iPod, la mayoría de los sitios web te muestran versiones de menor calidad. Esto se debe a que si bien estoy seguro que el Mini en el iPhone tiene mucho para dar, hacia las páginas web se ve como si las estuviésemos visitando con un navegador que solo esta en dispositivos de menor potencia.
No se bien como se podrá solucionar esto (jugando con el user agent quizás), pero así como esta la experiencia muchas veces es fea. Ir a un sitio que te obliga a ver la página como si la estuvieses navegando en un k310, y no oree ver el sitio full es feo. Eso pasa con gMail, Facebook, Clarin, entre otros.

En resumen, es una muy buena alternativa al Safari, pero hay cosas en las que todavía no lo reemplaza. Es algo positivo que Apple haya aprobado esta app, aunque es incierto qué pueda llegar a implicar. Y definitivamente estoy esperando updates

Tenía muchas ganas de poder tener en Latinoamérica algún evento como los que tienen en Europa, o Estados Unidos, en donde el centro de la cuestión sea el código fuente. Un evento en el cual poder hablar en nuestra lengua natal, el querido Español, sobre temas en los que casi siempre hay que conversar en Inglés. Un evento en el cual conocer gente con intereses similares y hacer nuevas amistades. Un evento para desarrolladores.

Esa meta parecía tan distante... Hasta que a principio de este año, una tarde reviso el correo y veo una noticia que me alegró el resto del día. Una propuesta para realizar el primer mozilla addons workshop en Latinoamérica. Realmente no lo podía creer, era como un sueño hecho realidad. Y así comenzó la aventura, el sueño se había cumplido, ahora había que vivirlo!

Prácticamente ya tenía las valijas listas para salir hacia mi entrenamiento como Jetpack Ambassador en las oficinas de Mozilla en Mountain View (sobre lo que ya escribiré!), y ahora tenía una invitación para mi primer evento como Jetpack Ambassador. La emoción era enorme... y también lo era la responsabilidad. Está claro que la responsabilidad de asistir a un workshop no es ni remotamente parecida a la de dar el workshop, pero a veces hay que hacer pequeños sacrificios para lograr lo que se quiere. Como decía mi abuela: el que quiere celeste, que le cueste.

Así que luego de concluido mi entrenamiento en Mozilla, empecé a darle forma a las secciones que me correspondían en el MAOW de Lima. Decidí que lo mejor era primero dar una introducción a Jetpack, dado que probablemente nadie supiera siquiera de la existencia del mismo. Luego presentaría un taller, con cosas simples para que la audiencia no se perdiera tanto. Y por suerte resultó, y a los asistentes les entusiasmó.

La experiencia del taller fue magnífica, y como las sesiones de Jetpack vinieron después de las extensiones normales, los resultados fueron muy gratificantes. Ver cómo la gente se sorprendía con la simplicidad de Jetpack, y que pensaran que con algo así sí podrían crear una extensión, me pareció un gran éxito para la plataforma. Los asistentes por lo general habían tenido alguna experiencia programando páginas web, pero no todos eran gurús del cyberespacio. Justamente el publico al que Jetpack apunta!

Antes de finalizar el MOAW, hicimos una pequeña competencia a ver quién lograba modificar una extensión base para agregarle un poco de comportamiento, y así regalábamos algunos premios . De nuevo fue sorprendente que las primeras personas en lograrlo lo hayan hecho en menos de 10 minutos. ¡Entendían lo que estaban haciendo pese a que nunca habían programado una extensión! Eso es en mi opinión una excelente primera impresión.

Las personas que se acreditaron premios fueron las siguientes, en orden de llegada:

1. Davis (@davis_laban)
   
2. Cristian (@criso)
   
   
3. Ulises (@ulisescab)
   
   
4. Yannick (@ywarnier)
   

Estoy muy agradecido de todos los asistentes al taller, de sus críticas y comentarios que nos vienen súper útiles para los próximos MAOWs que seguramente realizaremos . Ya he visto por ahí en Twitter que algunos están probando Jetpack, creo que no puedo estar más satisfecho y espero que algún día logren superar al maestro!

Antes de despedirme quiero agradecer a Percy Cabello, Daniel Yucra y Mozilla Perú por haber hecho realidad este evento. También a mi compañero Jorge Villalobos, que me acompañó en el taller dando la parte de Extensiones Tradicionales. Y a todos los demás encargados de que el taller saliera a la perfección y casi sin contratiempos!

1. Conocer a más desarrolladores de productos de Mozilla que sean hipanoparlantes
2. Difundir las tecnologías de Mozilla en Latino América, ¡qué el mundo nos oiga!
3. Hacerme de tiempo para dedicarle a la seccion de Labs de Mozilla Hispano
4. Difundir Jetpack.
5. Organizar el MozDay para Desarrolladores!!

Copia y pega este mensaje, cambia los cinco puntos por los tuyos y publícalo en tu blog

Si alguna vez te preguntaste cómo están hechos todos esos complementos de Firefox, probablemente hayas descubierto (quizás con alguna decepción) que no son tan fáciles de programar. Tenés que aprender un lenguaje llamado XUL para la UI, asimilar un montón de nuevos términos como Overlays, XPI, XPCom... Pero che, no estoy diciendo que todo esto es imposible de aprender (de hecho hay un montón de documentación y tutoriales disponibles), sino que simplemente hay que aprender algo nuevo.

Así que Mozilla pensó sobre esto por un tiempo, y salieron con una idea bastante piola: lo más probable es que vos ya conozcas JavaScript, CSS y HTML. Por qué deberías tener que aprender algo nuevo? Y así nació Jetpack, una nueva forma de programar complementos, en tan sólo un archivo y completamente programados en JavaScript, CSS y HTML.

Firebug y Jetpack

Y qué relación tiene Jetpack con Firebug? Bueno, bastante. Como dicen en el sitio de Jetpack, "para no reinventar la rueda" usaron Firebug para depurar y loguear. Hasta ahora todo perfecto: una manera simple para desarrollar complementos, un lindo depurador... qué más se podría pedir?
Quizás que ambos funcionen juntos ni bien los instalamos?

Como algunos se han dado cuenta, las últimas versiones de Firebug y de Jetpack no funcionan bien juntas de entrada. Esto es porque la versión actual de Jetpack (0.6.2) usa una vieja llamada a la API para comunicarse con Firebug, que cambió en la versión 1.4.3. Al parecer desarrollaron toda la interacción con Firebug usando Firebug 1.4.2, con lo cual nunca se enteraron del cambio en la API de Firebug. Pero a no desesperar! Hay una solución para esto, y es tan simple como cambiar una sóla palabra en una sóla linea de código.

Haciendo que ambos vuelvan a llevarse bien

Nota importante:
Al momento de escribir este artículo el bug abierto para este problema ya está en "Verified and Fixed", lo cual siginifica que el arreglo estará disponible en la próxima versión de Jetpack. Mientras tanto, vas a tener que hacer la siguiente modificación a mano para poder usar Jetpack con un Firebug 1.4.3 o posterior.

Primero que nada, vas a tener que ubicar tu perfil de Firefox. Esto depende de tu sistema, pero acá están algunas de las ubicaciones más comunes:

• Linux:
  ~/.mozilla/firefox/<profile folder>

• Mac OS X:
  ~/Library/Mozilla/Firefox/Profiles/<profile folder>
  Ó
  ~/Library/Application Support/Firefox/Profiles/<profile folder>

• Windows XP:
  C:\Documents and Settings\<Windows login/user name>\Application Data\Mozilla\Firefox\Profiles\<profile folder>

• Windows 7:
  C:\Users\<Windows login/user name>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile folder>

Si estás usando Firefox 3.6, podés ir a la URL "about:support" y ahí hay un botón que te lleva a la carpeta con tu perfil.

Una vez encontrada la carpeta de tu perfil, vas a tener que ir a esta carpeta que se encuentra dentro del mismo:

extensions/jetpack@labs.mozilla.com/content/js/xul

y editar el siguiente archivo:

firebug-extension.js

Cambiando la línea 19 de:

Firebug.URLSelector.watchBrowser(browser);

A:

Firebug.Activation.watchBrowser(browser);

Guarda el archivo, reinicia Firefox, y voilà, ahora Firebug y Jetpack deberían estar trabajando juntos!

Probando si Firebug está funcionando

Si querés saber si Firebug está funcionando como lo esperado, copiá el siguiente código en la parte de "Develop" en Jetpack:

jetpack.future.import("menu");

jetpack.menu.context.page.add({
    label: "LoguearEsto!",
    command: function(){
        console.log("Firebug está Andando OK");
    }
});

Ahora apretá el botón "Try out this code", habilitá Firebug y actualizá la página. Si todo salio bien, ahora debería haber una nueva entrada en el menú de contexto de la página, llamada "LoguearEsto!". Si hacés click en la misma, y en la consola aparece el texto "Firebug está andando OK", entonces Firebug está andando correctamente.

If you ever wondered how all those Firefox extensions are made, you probably discovered (maybe with some disappointment) that they're not that easy to code. You have to learn a language called XUL for the UI, assimilate a lot of new terms like Overlays, XPI, XPcom... But hey, I'm not telling this stuff is impossible to grasp (in fact, there's a lot of documentation and tutorials available), just that you have to learn something new.
So Mozilla thought about that for a while, and came up with a pretty cool idea: you are most likely to allready know JavaScript, CSS and HTML. Why you should have to learn something new? And thus born Jetpack, a new way to code Add-Ons in just a single file and entirely coded in JavaScript, CSS and HTML.

Firebug and Jetpack

And what has Jetpack to do with Firebug? Well, pretty much. As stated on Jetpack's site, "not wanting to reinvent the wheel" they used Firebug for debugging and logging purposes. So for now everything's great: a simple way to develop add-ons, and a nice debugger... what else could I ask for?
Maybe for them to work together out of the box?

As some people has noticed, the latest versions of Firebug and Jetpack won't work together right after installing them. This is because the current version of Jetpack (0.6.2) uses an old API call to communicate with Firebug that changed in version 1.4.3. It seems that all the Firebug interaction was developed using Firebug 1.4.2, so they never noticed the change in the API. But don't panic! There is a way to fix this, and is as simple as changing a single word on a single file.

Making them play nice together again

Important Notice:
As I write this article the bug opened for this issue is already Verified and Fixed, so that means that the fix will be on the next Jetpack release. Meanwhile, you'll have to do the following patch by hand to use Jetpack with Firebug 1.4.3 or later.

First of all, you have to locate your Firefox profile. This depends on your system, but this are some of the most common locations:

• Linux:
  ~/.mozilla/firefox/<profile folder>

• Mac OS X:
  ~/Library/Mozilla/Firefox/Profiles/<profile folder>
  OR
  ~/Library/Application Support/Firefox/Profiles/<profile folder>

• Windows XP:
  C:\Documents and Settings\<Windows login/user name>\Application Data\Mozilla\Firefox\Profiles\<profile folder>

• Windows 7:
  C:\Users\<Windows login/user name>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile folder>

If you are using firefox 3.6, you can go to the address "about:support" and there's a link to your profile folder.

After finding your profile folder, you'll have to go to the following folder inside it.

extensions/jetpack@labs.mozilla.com/content/js/xul

and edit this file:

firebug-extension.js

Changing the line 19 from:

Firebug.URLSelector.watchBrowser(browser);

To:

Firebug.Activation.watchBrowser(browser);

Save that file, restart Firefox, and voilà, Firebug and Jetpack are working together now!

Testing if Firebug is now working

If you want to test if Firebug is working as expected, then paste the following into the develop area of Jetpack:

jetpack.future.import("menu");

jetpack.menu.context.page.add({
    label: "LogThis!",
    command: function(){
        console.log("Firebug is Working OK");
    }
});

Now hit the "Try out this code" button, enable Firebug and refresh the page. If everything went right, you should have a new entry on the context menu of the webpage, called "LogThis!". If you click on that entry and the text "Firebug is Working OK" appears on the console, you have it working.

Hemos hecho un gran avance con John J. Barton en una nueva extensión para Firebug llamada Eventbug. Un agradecimiento enorme a Olli Pettay (smaug) por arreglar los bugs #448602 + #506961 y por brindar la nuevas API de Firebug que permiten enumerar los event listeners en una página web!

Tengan en cuenta que estas APIs están disponibles en Firefox 3.7a1pre (espero que puedan lograr entrar en Firefox 3.6) y también van a necesitar  Firebug 1.5 para poder hacer las pruebas.

Esta extensión trae un nuevo panel de Eventos que lista todos los manejadores de eventos de una página, agrupados por tipo de evento. El panel también se integra de una manera prolija con otros paneles de Firebug, y permite buscar rápidamente que elemento HTML está asociado con un event listener específico o ver su código fuente JavaScript.

Así que, veámoslo en acción!

Panel de Eventos

La captura de abajo muestra el contenido del panel de Eventos y los tres paneles de costado (click para ver la imagen en tamaño original).

Los paneles de costado son sincronizados con el listener que haya sido seleccionado en el área principal de contenido.

• Targets Muestra la lista de targets de eventos que serían usados como DOMEvent.currentTarget cuando el evento burbujee (bubblee). Todos los targets son clickeables y dirijen al usuario al panel de HTML
• Script Muestra el código fuente del listener seleccionado.
• HTML Muestra el código HTML del elemento que está asociado con el listener seleccionado.

Panel HTML

La extensión también registra un nuevo panel de costado para Eventos en el panel de HTML.

En este caso, el panel lateral de Eventos muestra todos los event listeners registrados para el elemento HTML seleccionado.

Configuración Recomendada

Firefox 3.7a1pre
Firebug 1.5b1
Eventbug 0.1a2

Errores Conocidos

Eventbug todavía está en una etapa alfa, y hay algunos errores conocidos..

• El panel no es actualizado si los listeners son agregados o eliminados dinámicamente dependiendo de acciones del usuario. Tu tienes que hacer click manualmente en el botón de Actualizar (Refresh, en la barra de herramientas). esto va a ser arreglado tan pronto como se solucione el bug #524674 (gracias Smaug! )
• Si un listener es definido usando un atributo HTML (i.e. click="alert('Hola Mundo!')" ) el código fuente no es compilado hasta que el listener es efectivamente ejecutado (es una optimización de Firefox). La UI de Eventbug no indica esto, y puede pasar que el link que lleva al código fuente de un listener no funcione. El link debería ser deshabilitado si el objeto script no está disponible.
• El panel lateral de Script todavía no deja crear puntos de interrupción.

Y por cierto, como es usual, si tienes cualquier idea acerca de cómo mejorar esta característica, háznoslo saber dejando un comentario aquí o en el grupo oficial (en inglés). Si encontrás un bug, por favor reportalo.

Gracias!

Agradecimientos Especiales a Mike Sabine Radcliffe por sus nuevas mejoras para el inspeccionador! Mike realizó unas impresionantes investigaciones y soluciones para los errores del inspeccionador. Ahora el inspeccionador de la 1.5 es muy sólido.

Ahora estamos a la espera de comentarios de los usuarios y reportes de errores. Esperamos tener alrededor de seis a ocho semanas para arreglar los errores en la 1.5. Una vez que Firefox 3.6 esté disponible, ya vamos a tener lista la mayor parte del trabajo en la 1.5 excepto por unos pocos ajustes o arreglos. Así que ahora es el momento para probar 1.5 en tu sitio web y hacérnoslo saber.

Al final aplicamos un montón de cambios para esta beta, así que voy a cubrir los cambios desde la 1.5a26 en un principio, luego en otro post haremos una descripción más en detalle del resto de las características.

Nota: Lo siguiente lo dejo en inglés ya que es un listado de los bugs que fueron arreglados de la 1.5a26 a la 1.5b1

• Locale is-IS, Icelandic (Iceland), contribution by Kristjan
• vi-VN locale (contribution by loveleeyoungae)
• Issue 2371: Placement of numbers indicating offset/margin/border/padding prevents display of more than 3 digits in the value
• Issue 2373: inspect hightlight wrong when scrolling
• Issue 1652: Negative Margins Show As Positive
• Issue 1897: Add indicator for position:relative (like margin and padding indication).
• Issue 2242: [req] hover overlay enhancements: negative margins and positioning
• Issue 2403: Universal CSS selector can cause issues with inspect
• Issue 1896: FB Panels with no options should disable selection of the options pulldown
• Issue 2378: Inspector is slightly slower now that the quick info box has been added
• Issue 2382: Search field hidden by ‘next previous’ popup when firebug in new window that is maximised
• Issue 1909: DOM – Copy field name contribution by blindwanderer
• Issue 2061: ‘Net’ tab shows requests under the wrong file type
• Issue 2383: Show Quick Info Box stays on top of element to inspect
• Issue 2390: “Inspect Element” doesn’t activate HTML tab in Firebug window
• Issue 2392: Object in DOM tab doesn’t refresh properly
• Issue 206: UI gets stuck with both Edit and Inspect buttons pushed on CSS panel
• Issue 1172: Enhancement: Display Firebug icon next to “Inspect Element” context menu item
• Issue 2393: Quick Info Box needs a keyboard shortcut
• Issue 2394: Layout information shows the wrong values
• Issue 2396: Inspector options difficult to find in the Firebug options menu
• Issue 425: On RTL Systems the console text box is RTL too. It should allways be LTR.
• Issue 594: Classin skin: warning icon looks weird
• Issue 2399: Open with editor does nothing on Vista
• Issue 1009: Firebug improperly retains scroll position in “Style” pane
• Issue 1017: “Show functions defined by the user” in DOM tab includes internal functions
• Issue 2401: HTML mutate flag is not always removed
• Issue 1721: Tries to “display” -moz-binding url
• Issue 2402: Cannot overlay the fbToolbox as there are two elements with that ID in the DOM
• Issue 2403: Universal CSS selector can cause issues with inspect
• Issue 2406: Quick Info Box stays visible when changing Firebug Tabs
• Issue 2407: Quick Info Box does not always move on mouseover
• Issue 2063: Error message “The resource from this URL is not text”
• Issue 1966: Error traceback no longer always picks up the right function names.

Ver el post Original.

Esta es la segunda parte de la Encuesta sobre Características de Firebug (acá está la primer parte). Esta vez, enfocándome en las respuestas a la pregunta: ¿Cual es la característica de Firebug que menos te gusta? ¿Y la que nunca usás? No se si la pregunta estaba mal formulada o si la gente tenía ganas de expresarse, pero muchos de los encuestados no se limitaron a sólo una cosa. Como resultado, tuve que modificar un poco mi para nada científica metodología y contar las características mencionadas como votos, en vez de sólo clasificarlas en categorías.

Como en la encuesta anterior, agregué una columna de "Basura" para las respuestas que realmente no tenían sentido. Es muy bueno escuchar "Yo <3 Firebug!" (y Firebug te <3 a vos también!) pero no ayudaba mucho en los objetivos de esta encuesta. Complementando esta columna, creé otra categoría para las respuestas lamentándose por la estabilidad de Firebug o la ausencia de ciertas características específicas. Esta categoría empató en el primer puesto, con la mayor cantidad de votos.

Los Ganadores

Tercer puesto – Empate!

• La Búsqueda
• Consola. Me sorprende que haya algunas personas a las que no les gusta la consola, pero dos de ustedes piensan de esa manera. Una persona mencionó que aparecen un montón de excepciones provenientes del navegador, degradando la calidad de la información. Estas excepciones por lo general pueden reducirse de-seleccionando la opción "Mostrar Errores de Chrome" y las opciones de mensajes en el mini-menu del panel de Consola.

Segundo puesto – Empate!

Estos tienen la sospechosa distinción de tener la misma cantidad de respuestas que la columna de Basura (Junk).

• Panel CSS
• Panel DOM
• Perfilador

Primer Puesto

• Panel de Script — Las respuestas variaron desde "No se cómo utilizar las interrupciones" hasta usuarios que prefieren usar la consola para hacer depurado interactivo al estilo del printf. Otros encuestados demandaron que el panel de script era demasiado defectuoso.

advertencia: Creo que es probable que exista más de un tipo de usuario de Firebug. Alguno de ellos pueden no estar usando Twitter y esta encuesta no les habrá llegado. Los tipos de usuarios que respondieron y dijeron que su característica favorita era el Inspeccionador de HRML y la edición en vivo de CSS son probablemente el mismo grupo de personas que no hacen un uso extensivo del depurador de Scripts. Si sos un arduo depurador, por favor exprésalo en los comentarios.

Menciones Honorables

• Editor de nodos HTML – Si haces doble click en un tag en la vista HTML, verás un editor de nodos. Haciendo click en el boton "Editar" o usando la tecla Escape te sacarán de ahí.

• Registración de Eventos – haz click derecho en un nodo en el panel HTML y selecciona "Registrar Eventos". Ahora cada mousemove, click y keytroke en ese nodo será registrado en la Consola. Cómo puedes no amar eso?

No hubo ningun voto(!) para el panel de Red, así que claramente todo el mundo lo ama y piensa que es alucinante.

Conclusiones

• Necesitamos trabajar más duro en arreglar errores y problemas de estabilidad. Emplear un montón de esfuerzo en estabilidad y usabilidad probablemente sea una muy buena manera de hacer de Firebug una mejor y más placentera pieza de software.

• Las pestañas de CSS y DOM no son muy queridos. Agregar una mejor navegación a la página de DOM, o rehacerla por completo puede ser útil. Deshacerse por completo de él y el panel de CSS puede ser otra opción, pero no una que queramos considerar sin ver una fuerte devolución desde la comunidad.

• El Perfilador va bastante bien con el panel de Script. Si no estas haciendo una fuerte depuración de JavaScript, puede que no necesites el perfilador. Es una herramienta de un uso bastante específico para medir la performance del JavaScript de una página.

• La Búsqueda fue casi una sorpresa, pero la estamos mejorando para la versión 1.5 así con un poco de suerte se vuelve más sencilla de usar.

Al igual que antes, por favor déjanos tus comentarios si piensas que algo se nos pasó por alto.