Firefox : une première ébauche du nouveau débogueur open source

Firefox : une première ébauche du nouveau débogueur open source

Déjà compatible avec Chrome et Node.js

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

19/09/2016 4 minutes
32

Firefox : une première ébauche du nouveau débogueur open source

Mozilla planche actuellement sur une réécriture complète du débogueur inclus dans Firefox. L’éditeur se prépare à se débarrasser de l’ancien composant écrit avec son langage XUL et se dirige vers une version plus modulaire créée à partir des bibliothèques React et Redux. Une première ébauche peut être testée dans les Nightly du navigateur.

Le débogueur est un composant particulièrement important des navigateurs. Il fait partie des outils proposés aux développeurs pour les aider à concevoir leurs sites et applications web. Ces outils sont l’une des forces de Firefox, Mozilla ayant toujours veillé à garder un avantage dans ce domaine. Mais ils utilisent parallèlement le langage XUL, ouvert mais propriétaire, dont l’éditeur se débarrasse petit à petit.

Dans le cas du débogueur, la réflexion était en cours depuis un moment : faut-il moderniser le code existant ou tout repenser ? C’est la seconde approche qui a finalement été retenue. Elle permet de retravailler le composant avec deux objectifs précis : fournir une structure modulaire modernisée et en faire un élément générique qui pourra être réutilisé ailleurs. Le débogueur ne sert pas en effet que pour Firefox.

Mozilla veut se débarrasser de XUL sur l'ensemble des outils

Mozilla réécrit donc intégralement son débogueur et a présenté en fin de semaine dernière une première ébauche de son debugger.html. Le code s’appuie uniquement sur les technologies du web, en utilisant notamment les outils open source React et Redux, créés par Facebook. React en particulier est une bibliothèque régulièrement utilisée pour la conception d’interface dynamiques, une variante native existant pour les applications mobiles.

Dans un billet de blog, le responsable des outils développeurs, Bryan Clark, indique que l’ancien code en XUL (XML User Interface Language) était complexe à entretenir : « L’ancien débogueur était incroyablement difficile à modifier, en bonne partie à cause de XUL. XUL est une toile d’araignée de composants de modèles et de vues qui empêchait souvent les changements les plus simple d’être facilement réalisés ».

Une grande partie du travail a consisté à revoir le modèle de développement, le code se retrouvant découpé en modules plus petits. « Nous pensons que cela rendra le débogueur et tous nos outils de développement plus faciles à aborder, prévisibles, compréhensibles et testables. » C’est parallèlement une réécriture de longue haleine et il ne faut pas attendre de résultats finalisés avant un bon moment, seule une préversion étant pour le moment disponible.

Une interface divisée en trois zones

Cette dernière présente une interface en trois panneaux. La partie de gauche s’occupe d’afficher les sources du site ou de l’application web en cours de débogage. Au centre, la plus grosse partie de l’écran est consacrée à l’éditeur lui-même pour intervenir sur le code lui-même. Quant à la zone de droite, elle affiche la pile des appels, les breakpoints ainsi que les variables quand le débogueur est à l’arrêt.

Le nouveau debugger.html est intégralement open source et dispose de son propre dépôt sur GitHub. Au sein de Firefox, il se connecte au navigateur via le Firefox Remote Debugging Protocol. Mais puisqu’il s’agit d’un composant qui se veut aussi générique, on peut le « brancher » sur Chrome et Node.js via le Chrome Debugging Protocol également. Mozilla travaille même à rendre son composant intégrable dans un autre éditeur pour être utilisé en tant que CLI (Command-line Interface).

debugger firefox débogueur html

Renforcer la compatibilité avec les autres plateformes

Au cours des prochains mois, le projet va continuer, avec un accent mis sur la facilité à aborder le nouveau composant, notamment pour tous ceux qui veulent participer. Mozilla tient également à rendre son débogueur plus accessible sur les autres plateformes, la compatibilité avec Chrome et Node.js n’étant qu’un premier pas. Pour tester debugger.html, il suffira de récupérer la dernière version Nightly depuis le lien ci-dessous. Pour rappel, il s’agit de versions très peu testées dans lesquelles Mozilla expérimente ses nouveautés. Elles s’installent en parallèle des canaux final/bêta et Aurora, qu’elles ne remplacent donc pas.

debugger firefox débogueur html

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Mozilla veut se débarrasser de XUL sur l'ensemble des outils

Une interface divisée en trois zones

Renforcer la compatibilité avec les autres plateformes

Fermer

Commentaires (32)


Pourquoi tout blanc et bright? ils peuvent pas faire un truc leger pour les yeux? c’est pas pour rien que les gens pefere les themes dark








Vincent Hermann a écrit :



Mais ils utilisent parallèlement le langage XUL, ouvert mais propriétaire, dont l’éditeur se débarrasse petit à petit.





Comment dire, une chose et son contraire dans la même phrase <img data-src=" />.

Je pense que ce que vous voulez dire, c’est que XUL est ouvert, mais pas standardisé par un organisme indépendant.



Si c’est du html/JS, y’aura assez vite des thèmes CSS, officiels ou non.


Du code peut être ouvert (dispo sur un dépot), mais pas libre (pas possible de proposer des améliorations).

De nombreux composants propriétaires proposent ce mode de fonctionnement, afin de rassurer leurs clients tout en gardant le contrôle.


Sauf que en l’occurrence, le code de Mozilla est bien libre.



Normalement ouvert (dans le sens Open Source) signifie bien plus que déposé sur un dépot.&nbsp; Et si on compte “ouvert” comme ouvert à la discutions dans un comité indépendant, dons ce cas là, il faudrait dire au contraire “libre, mais non ouvert”


Firefox the best !!! <img data-src=" />








Naneday a écrit :



Pourquoi tout blanc et bright? ils peuvent pas faire un truc leger pour les yeux? c’est pas pour rien que les gens pefere les themes dark





C’est qui les gens dont tu parlent ? je pense qu’on ne connait pas les même …









Naneday a écrit :



Pourquoi tout blanc et bright? ils peuvent pas faire un truc leger pour les yeux? c’est pas pour rien que les gens pefere les themes dark







Il suffit de change de thème, il y en a déjà un pour le dév qui est sombre.



euh… tout le monde ne préfère pas les thèmes dark !








Naneday a écrit :



Pourquoi tout blanc et bright? ils peuvent pas faire un truc leger pour les yeux? c’est pas pour rien que les gens pefere les themes dark





Franchement, c’est probablement au pied de la liste. En tout cas je l’espère !



Les mecs s’arrachent pour proposer un outil complet, demandent des retours, et on leur dit que le thème serait mieux en sombre !



ENFIN !








RRMX a écrit :



Franchement, c’est probablement au pied de la liste. En tout cas je l’espère !



Les mecs s’arrachent pour proposer un outil complet, demandent des retours, et on leur dit que le thème serait mieux en sombre !





Je pense que ce sera inclus. C’est un changement assez trivial et classique pour les UI pour dev. Tu as toujours une UI claire et une sombre.



Moi aussi ça m’a fait tiquer. Je suis allé sur Wikipedia et XUL n’est pas du tout propriétaire, c’est même sous licence MPL:https://en.wikipedia.org/wiki/XUL


Je pense qu’il faut comprendre le “propriétaire” de XUL dans le sens de “non standard”, qui leur est propre.


Oui c’est juste qu’il a complètement inversé les deux termes. C’est bien libre et open source, donc non propriétaire : tout le monde peut l’utiliser et le faire évoluer comme il veux.




Par contre le terme ouvert est  assez vague. Si on prend ce mot dans le sens de spécification standardisée par un comité&nbsp;  ouvert à la participation de tous, alors en effet le XUL n'est pas  totalement ouvert. C'est une technologie qui évolue avant tout a  répondre aux besoins de Mozilla.

La liste des alternatives est longue, pouvoir tester le produit dans de bonne conditions c’est non négligable



Quand tu passes plus de 10h a coder dans une journée je t’assure que le theme dark c’est plus qu’utile..


Ceux qui devs pendant plus de 8heures non stop si :p


Ceux qui devs plus de 8h par jour non stop


Inutile de prendre ton cas pour une généralité, personnellement je peux tout à fait faire des journées complètes sur un écran blanc et noir.



Râler sur un détail alors qu’on en est à la phase alpha, c’est juste a coté de la plaque. Il est évident que ça sera paramétrable dans le produit final, comme dans tous les produits du genre. Le but d’une preview c’est pas de faire le plein d’utilisateurs quotidiens.


Je prend pas mon cas pour une generalité.. enfin bref on voit pas les choses du meme point de vue, alpha/beta si c’est destiner a un public extern a l’entreprise, rien que pour l’image de la marque, je prefere fournir un produit qui conviendra au plus de gens possible, donc light/dark theme oblige



En tant que tester potentiel, ben no dark theme, no test pour moi c’est simple








Naneday a écrit :



Je prend pas mon cas pour une generalité.. enfin bref on voit pas les choses du meme point de vue, alpha/beta si c’est destiner a un public extern a l’entreprise, rien que pour l’image de la marque, je prefere fournir un produit qui conviendra au plus de gens possible, donc light/dark theme oblige



En tant que tester potentiel, ben no dark theme, no test pour moi c’est simple





En même temps j’ai du mal a comprendre pourquoi tant de discussion sachant qu’on ne sait pas si il y a un dark thème ou pas.



D’après ce que je comprends du lien Wikipedia, c’est proprio au sens où seul Gecko prend en charge la techno et que ses specs ne sont pas ouvertes et donc non interopérable pour l’implémenter dans un autre moteur de rendu.



Le terme est sans doute malheureux (mais la source de l’info le dit bien comme ça), mais pour moi c’est à prendre au sens où c’est une techno propre à Mozilla.




Mozilla veut se débarrasser de XUL sur l’ensemble des outils



tant qu’ils cassent pas la compatibilité avec les addons écrits en XUL, ça me va.

Sinon, je vais devoir chercher un dev qui veux bien réécrire mon fork de resurrect-pages en whatever… d’ailleurs, je sait même pas si c’est encore possible de le faire vu les spécificités… (greffer du code sur la page d’erreur de firefox)


C’est bien documenté en tout cas :https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL



Après XUL est obsolète pour Mozilla et il n’y en aura plus une trace d’ici peu.


Certain addons devront être réécrit il y a un post sur le blog mozilla



Ainsi qu’un FAQ sur les WebExtensions avec pas mal d’infos sur des cas particulier.



Les addons basés sur XPCOM, XUL et XBL sont dépréciés.








SebGF a écrit :



D’après ce que je comprends du lien Wikipedia, c’est proprio au sens où seul Gecko prend en charge la techno et que ses specs ne sont pas ouvertes et donc non interopérable pour l’implémenter dans un autre moteur de rendu.





XUL est au contraire plutôt bien documenté. Seul Gecko supporte la techno, mais c’est plus un état de fait qu’une volonté de Mozilla qui au contraire a tout fait au début pour permettre son essor.



&nbsp;Mais bon maintenant que le HTML assez évolué pour permettre de faire des IHM utilisable pour des applications de bureau, il est normal qu’il ne souhaitent plus s’engager d’avantage dessus et de favoriser la technologie qui est au centre de leur application.







Albirew a écrit :



tant qu’ils cassent pas la compatibilité avec les addons écrits en XUL, ça me va.

Sinon, je vais devoir chercher un dev qui veux bien réécrire mon fork de resurrect-pages en whatever… d’ailleurs, je sait même pas si c’est encore possible de le faire vu les spécificités…





XUL est malheureusemenbt condamné a terme, surtout pour les extension. Il faut voir que si techniquement ce système offres des possibilité de personnalisation quasi-illimités, les emmerdes que les addon peuvent entrainer le sont aussi.



Ton addon est certainement portable vu que il y a une extension toute neuve qui fait a peu près ça (sauf que c’est limité a Web Archive) dans Test Pilot, soutenu par Mozilla.



Il y a un thème sombre. x)








Nerach a écrit :



C’est bien documenté en tout cas :https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL



Après XUL est obsolète pour Mozilla et il n’y en aura plus une trace d’ici peu.









Uther a écrit :



XUL est au contraire plutôt bien documenté. Seul Gecko supporte la techno, mais c’est plus un état de fait qu’une volonté de Mozilla qui au contraire a tout fait au début pour permettre son essor.







Je parlais bien d’implémentation et d’interopérabilité.

Si le langage est bien documenté pour être exploité, d’après ce que j’ai compris, il ne l’est pas pour être implémenté dans un moteur de rendu autre que Gecko.

Ce qui fini par limiter rapidement l’attrait au final, surtout pour un produit censé être “ouvert” et “libre”.



Juste une remarque, mais comme pour Pocket, Hello, et d’autres fonctions annexes au simple rôle de “browser”, l’intégration au sein de Firefox d’un outil ciblant une population particulière d’utilisateurs, au pourcentage très faible dans ce cas du développement, ne me semble pas une bonne idée. La mise à disposition sous la forme d’extension me paraîtrait plus logique.



Quitte à ce qu’elle soit préinstallée (et désinstallable simplement) dans une version “développeur” de Firefox.

Mais qu’au moins la version grand public soit allégée au maximum et optimisée pour la vitesse.

Ou qu’il existe une version “Light” débarrassée de ces outils et centrée sur le moteur de rendu de pages.



Puisque maintenant elle passe par une API, ça devrait être envisageable, non ?


Autant mon IDE à un theme sombre, autant pour les outils de deboggage navigateur je suis revenu sur les theme clair fans FF et Chrome.



&nbsp;


Non, non, pas tous…


Remplacer du complexe et dépassé par du complexe et dépassé. Ah.