Re: Tree Style Tab, NoScript, Pentadactyl, etc ...

Tant mieux. Je n'avais pas vu ce billet, je l'admets. Cependant, deux réserves :

• Comme je l'ai mentionné, il est tout à fait possible pour Mozilla d'implémenter son API WebExtension de telle façon à ce que toutes les extensions actuelles puissent y être portées. Aucun doute là-dessus. Cependant, dans ce cas, on ne règle aucun des problèmes qui sont à l'origine du passage à WebExtension. La question est donc de savoir jusqu'à quel point Mozilla acceptera que les extensions aillent jouer dans les tripes de son navigateur. Si j'ai une extension d'accessibilité qui modifie le rendu des pages, est-ce que Mozilla va laisser implémenter des hooks sur Gecko pour le permettre? Si oui, est-ce que ces hooks vont être conçus de telle façon à ne pas interférer avec les changements sur Gecko? Pas facile du tout. Si mon extension doit faire redémarrer le navigateur, est-ce que ça va être possible? Dans le billet que tu cites, le gars donne en exemple l'utilisation d'une "SideBarAPI" pour implémenter TreeStyleTab. C'est bien beau, sauf que ce genre de chose existe déjà dans Chrome, et qu'on n'y retrouve pourtant aucune extension similaire. Pourquoi? Parce qu'il y a une différence entre faire une sidebar quelconque (présentant l'historique de manière différence par exemple) et une sidebar qui interagit aussi profondément avec le navigateur. Le billet donne lui-même un exemple : il faudrait avoir moyen de cacher les "vrais" onglets via WebExtension. Je peux t'en donner plusieurs autres : il faut être en mesure d'arrêter le chargement d'une ou plusieurs pages (lorsque l'utilisateur ferme un onglet ou un groupe), d'annuler la fermeture d'un onglet, d'actualiser un ou plusieurs onglets à la fois, de gérer le glisser-déposer de liens ou d'onglets d'autres fenêtres, etc. Encore une fois, ce n'est pas impossible, mais dire "on va juste laisser les extensions créer une sidebar et ça va permettre de réimplémenter TreeStyleTab" est très réducteur, et dire "ne vous inquiétez pas, rien ne va changer pour vous" est quasi-impossible pour Mozilla sans revenir en arrière sur ses objectifs avec WebExtension.
• Admettons que Mozilla réussit à conserver les extensions les plus populaires (qualificatif qui reste à définir, soit dit en passant). Quid des autres extensions, des trucs qui pourraient être développées et avoir besoin du support d'une API particulière pour le faire? J'ai vu plusieurs extensions vraiment intéressantes (d'un point de vue hacker) qui décomposaient par exemple le rendu d'une page et l'affichage des éléments, et, même au-delà de ces cas d'école, il y a formellement plein de choses qu'on peut vouloir faire pour améliorer un navigateur; supposer que les usages actuels seront toujours suffisant, c'est très limite. Le gars semble d'ailleurs le savoir, puisqu'il écrit :

We want people to be able to experiment with new ideas, and they shouldn’t have to wait for us to design, implement, and finalize a new API. However, we don’t want this to become another feature like require('chrome') in Jetpack, which is used by virtually every add-on. We’re still trying to figure out how to avoid that fate. We know that we need to be more proactive about providing APIs that add-ons need. But is that enough?

En gros, ils ne savent pas vraiment encore.

Bref, génial pour les extensions actuelles, mais j'attends quand même de voir ce que les discussions avec les devs des extensions vont donner et le bénéfice réel pour le développement de Firefox en bout de ligne.