Aller au contenu | Aller au menu | Aller à la recherche

Pourquoi les extensions sont désactivées dans une nouvelle version de Firefox ?

Beaucoup s'interrogent sur le fait que des extensions qu'ils ont installés dans Firefox 1.0, soient désactivées automatiquement lorsqu'ils testent par exemple Firefox 1.5 beta. Voici quelques explications.

Il faut savoir que l'interface utilisateur d'une application Mozilla comme Firefox, est définie dans un fichier XML (langage XUL). Ainsi, que ce soit la fenêtre principale, ou les boîtes de dialogues, tout est défini par des fichiers XUL.

Il y a aussi un mécanisme un peu spécial dans Mozilla : les overlays. C'est un moyen de modifier un fichier XUL sans y toucher. Un overlay se résume en fait à un second fichier XUL, dans lequel on fait référence à des éléments au premier fichier XUL. De ce fait, un overlay est lié à la structure du fichier XUL original.

C'est par ce mécanisme d'overlays que les extensions peuvent ajouter un menu, un bouton ou tout autre élément dans l'interface du navigateur, sans que les fichiers propres au navigateur soient modifiés physiquement.

Or d'une version à une autre, les fichiers XUL d'une application comme Firefox sont susceptibles de changer. Aussi, une extension fonctionnant très bien pour une version 1.0 peut ne plus fonctionner (ou plutôt apparaître) dans une version 1.5, puisque des éléments dans les fichiers XUL ont pu disparaître, ou être modifié.

C'est pourquoi les extensions ne sont prévues que pour une ou plusieurs versions spécifiques de Firefox. Et c'est spécifié dans un des fichiers de l'extension. Quand on installe une nouvelle version de Firefox, celui ci désactivent les extensions qui ne sont pas prévue pour sa version.

Bien souvent il suffit de changer le numéro de version de Firefox dans l'extension pour que celle-ci puisse être à nouveau utilisable. Mais ce n'est pas toujours suffisant, il faut certainement modifier les overlays. Tout dépend des changements qui ont été fait dans les fichiers XUL correspondant. Bien sûr, il y a aussi des évolutions dans les API de Firefox, et il peut aussi être nécessaire d'adapter les scripts de l'extension.

En résumé, les extensions sont prévues pour des versions spécifiques d'une application, et sont automatiquement désactivées pour les autres versions afin d'éviter des dysfonctionnements. Il faut donc installer une version de l'extension qui soit adaptée à la nouvelle version de l'application.

Commentaires

1. Le dimanche, octobre 2 2005, 01:36 par Talou

Bon résumé !

Et ce n'est pas fini, parce que les nightly viennent juste de passer à la version 1.5 apparement...

2. Le dimanche, octobre 2 2005, 06:47 par Denis Boudreau

OK, parfait. Et merci d'avoir répondu à ma question. Mais pourquoi c'est comme ça? Pourquoi ne pas tout faire pour les rendre indépendantes des versions, justement?

3. Le dimanche, octobre 2 2005, 10:23 par Dam

Denis > Ben cela me parrait difficile ... Une extention doit s'intégré dans le navigateur ... (des nouveau menu apparaissent pour lancer des commandes ou une sidebar), si le menu en question est supprimé d'une version de firefox pour un autre mecanisme meilleur (hypothese), ou comme dans les option un menu passe de la vertical a l'horizontale (peut influencé l'intégration des item je suppose encore que dans ce cas j'en soit moins sur) comment utiliser l'extention qui cherche à rentrer des items dans un menu qui n'existe pas ou qui à été aussi profondément modifié ...?

4. Le dimanche, octobre 2 2005, 11:29 par Frédéric

Certainement pas trivial, non, mais des dépendances entre composants distribués séparément, c'est gérable depuis des lustres, quand j'installe une nouvelle version de GTK+, Firefox ne se trouve pas désactivé...

Ce n'est pas l'impossible qui est demandé, il y a des cas où la compatibilité ne peut être assurée, mais la plupart du temps, comme l'écrit Laurent, « il suffit de changer le numéro de version de Firefox dans l'extension ». Ce sont ces cas-là, fréquents donc, qu'il serait super de pouvoir gérer.

Petite analogie avec le javascript dans les pages web, n'a-t-on pas souvent répété que non, il ne fallait pas tester sur le numéro de version (et le nom du navigateur) mais plutôt tester si la fonctionnalité demandée était présente ? C'est pareil ici je trouve, les extensions sont attachées à un numéro de version, elles devraient l'être à une/des fonctionnalité/s.

(mais j'ai commencé par dire que ce n'était pas trivial)

5. Le dimanche, octobre 2 2005, 13:59 par Laurentj

mais des dépendances entre composants distribués séparément, c'est gérable depuis des lustres, quand j'installe une nouvelle version de GTK+, Firefox ne se trouve pas désactivé...

Et pour cause, il utilisera l'ancienne version si elle est disponible. Si elle ne l'est plus, rien ne peut prédire du bon fonctionnement ou non de l'application. Si d'une version à une autre de GTK l'API change, les applications non compilées pour cette nouvelle version ne fonctionneront pas. On a une limitation des problèmes grâces au système d'interface (IDL) que l'on trouve dans les DLL de microsoft, et même dans Firefox (objets XPCOM), mais ça n'est pas encore la solution rêvé (si elle existait aujourd'hui, on aurait pas tout ces problèmes de dépendances sous linux, mac os ou même windows..)

De plus, autant figer une API dans le temps est faisable (c'est pour ça que quand tu installes une nouvelle version de GTK, la plupart des applis continuent de fonctionner), autant figer une interface utilisateur de version en version, ça l'est beaucoup moins. D'où ce risque d'extensions qui s'intégrent pas ou mal dans une nouvelle version, d'où cette limitation dans les numéros de versions.

pour ce qui concerne les scripts oui, il ne faut pas tenir compte d'une version. Mais il reste tout de même le problème que si la fonctionnalité n'existe plus, ou que son API a été modifié, le script ne fonctionnera tout de même plus dans une nouvelle version.

ce sont ces cas-là, fréquents donc, qu'il serait super de pouvoir gérer.

Dangereux tout de même. Je pense que tu parles de mettre à disposition par exemple d'un bouton "réactiver l'extension" pour l'utilisateur. Mais qui peut prévoir le comportement de l'extension ? Qui sait si l'extension ne va pas tout faire merder, voir même empecher un redémarrage correct de firefox ? Tu imagines le problème pour Henry et Lucette ?

C'est pour ça que les développeurs d'extensions specifient bien les versions de firefox pour lesquelles elles fonctionnent, et ne specifient pas que par exemple, l'extension est valable jusqu'à Firefox 3.0. Ils ne peuvent prévoir qu'elle fonctionnera ou non pour Firefox 3.0, parce qu'ils ne savent pas comment sera l'interface de FF 3.0 donc comment l'extension pourra s'intégrer, ce que proposera FF3.0 au niveau API etc..

Je pense que le modèle de fonctionnement des extensions est ce qu'il y a de mieux : au moins, le navigateur a beaucoup moins de risque de ne pas de planter lors d'une migration. Pour l'utilisateur, c'est rassurant. Il n'aura peut être pas toutes ses extensions préférées en état de fonctionnement, mais au moins, il pourra toujours surfer sur le web... pour mettre à jour ses extensions (si elles existent) ;-)

6. Le dimanche, octobre 2 2005, 14:11 par LaurentJ

Mais pourquoi c'est comme ça? Pourquoi ne pas tout faire pour les rendre indépendantes des versions, justement?

Chaque technique et système a ses inconvénients. Et ici, c'est l'inconvénient du système des overlays. tu as comme un calque (overlays) qui peut se superposer correctement à un dessin (fichier xul original). Si le dessin change dans le temps, le calque ne va plus se superposer correctement, forcément. Si tu as une solution pour que le calque puisse s'adapter automatiquement au dessin, quelque soit les évolutions du dessins, propose la vite à la fondation ;-)

C'est pareil pour XSLT. Une feuille XSLT prend en entrée un fichier XML dans un format précis. Si tu lui fournis un fichier ayant une structure légèrement différente, rien ne peut prévoir si la feuille XSLT va s'appliquer correctement (puisque, tout comme un overlay, une feuille XSLT fait référence à des elements ou ensemble d'élements bien précis du fichier XML en entrée, si ceux ne sont plus là, ou avec des attributs ou élements fils différents, comment peut s'effectuer la transformation décrite dans le fichier XSLT ?)

7. Le dimanche, octobre 2 2005, 16:33 par Mozinet

« Quand on installe une nouvelle version de Firefox, celui ci désactivent les extensions qui ne sont pas prévue pour sa version. » => Quand on installe une nouvelle version de Firefox, celui-ci désactive les extensions qui ne sont pas prévues pour sa version.

Pas de problème pour une suppression de ce commentaire après prise en compte :)

8. Le dimanche, octobre 2 2005, 18:53 par Frédéric

Désolé, je ne suis pas d'accord :)

> quand j'installe une nouvelle version de GTK+, Firefox ne se trouve pas désactivé...

Et pour cause, il utilisera l'ancienne version si elle est disponible

Non, et c'est justement là l'intérêt de définir des interfaces (terme volontairement vague), si j'installe une nouvelle version de GTK+, ou d'une autre bibliothèque utilisée par Firefox, quel que soit le système, Firefox continuera à fonctionner (et c'est tant mieux).

Grosso modo, .so, .dll ou autres, s'y trouve définie une liste de symboles. Au démarrage de Firefox, le système va vérifier que tous les symboles demandés par Firefox sont présents dans la bibliothèques, comme ce sera le cas, Firefox démarrera.

C'est un peu ce que je demanderais à Firefox et à ses extensions, celles-ci pourrait déclarer une liste de "symboles" utilisés et l'extension ne se trouverait désactivée que s'ils n'étaient pas présents.

Je ne demande pas que l'interface de Firefox soit figée et qu'aucune modification n'y soit apportée par soucis de ne rien casser, je voudrais juste qu'une extension puisse déclarer d'une manière ou d'une autre "j'ai besoin d'une barre d'état, de ce menu et de telle ou telle fonction" (cela rejoint ton « prévoir le comportement de l'extension »).

Dans 90% des cas, la nouvelle version de Firefox satisfera les besoins et l'extension sera donc utilisable. Dans les 10% restants, tant pis, elle se trouvera désactivée et je trouverai ça acceptable.

Encore une fois ce n'est pas trivial. Mais je trouve cela important dès lors qu'on se met à considérer Firefox comme une plate-forme et non comme un simple navigateur fermé sur lui-même.

9. Le dimanche, octobre 2 2005, 19:43 par Talou

Rectification, les nightly viennent de passer à la version 1.4.1

10. Le lundi, octobre 3 2005, 09:49 par Laurentj

c'est justement là l'intérêt de définir des interfaces

oui, je le repète, dans Firefox, les XPCOM sont accessibles via des interfaces (IDL, comme dans Corba ou COM)

Mais c'est oublié que la glue entre un fichier XUL et les objets XPCOM, c'est du javascript..

Au démarrage de Firefox, le système va vérifier que tous les symboles demandés par Firefox sont présents dans la bibliothèques

Ce n'est pas possible. Parce que cela demanderai de parser tous les fichiers javascript de toutes les extensions et package, de détecter toutes les instanciations d'objets XPCOM (ceux qui ont une interface définie), de vérifier qu'ils sont présents, et d'analyser tout le code javascript pour détecter là où il est fait appel aux méthodes de ces objets.

C'est tout à fait impossible car Javascript n'est pas un langage compilé. On ne peut tenir dans un coin une liste de "symboles" (surtout aussi à cause du caractère polymorphique du javascript, où on peut ajouter/redefinir à n'importe quel moment une méthode ou une propriété à un objet, même si celui ci est un mapping d'un XPCOM).

Et puis cette analyse au démarrage serait beaucoup trop longue.

à ses extensions, celles-ci pourrait déclarer une liste de "symboles" utilisés et l'extension ne se trouverait désactivée que s'ils n'étaient pas présents.

Une solution serait peut etre de lister dans un fichier tous les XPCOM et interfaces utilisées. Ça peut être séduisant, mais ça va vite devenir l'enfer pour le développeur. Et si il se trompe dans sa liste ?

j'ai besoin d'une barre d'état, de ce menu et de telle ou telle fonction

pour l'exemple de ta barre d'état ou de menu : beaucoup trop complexe.

Une solution pourrait être de parser au démarrage tout les overlays et de vérifier que leur contenu s'applique bien. Trop long, trop couteux. Car il faut alors aussi parser tout les fichiers XUL des tous les packages, pour voir quels overlays ils utilisent etc..

-> demarrage plus long, executable de firefox plus lourd. Ce n'est pas "rentable" en regard du peu de temps que cela coute au développeur de l'extension de faire les quelques vérifications et adaptations.

11. Le dimanche, octobre 9 2005, 01:58 par loufoque

Pas au démarrage, seulement à l'activation de l'extension. Par exemple, une extension est déclarée non créée pour la version de Firefox utilisée. Firefox pourrait proposer de vérifier si les overlays peuvent tout de même s'appliquer.