Firefox 3.6/Namoroka: Rumeurs et news sur le développement

[Uther]

Parce que je vois pas trop quoi y répondre. Oui le about config est une base de registre et souffre donc des mêmes défaut que celle de Windows.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090125 Minefield/3.2a1pre

[teoli2003]

Et pourquoi personne réponds à Zerflng?

Son intervention n'est pas honteuse et est très (im)pertinente

Comme le dit Uther, c'est exact. Et c'est bien l'une des raisons (pas la seule) pour lesquelles les profils de Firefox rouillent comme une install de Windows.

Perso je verrai bien les modifs de l'about:config stockés dans une base et lors de la désinstall d'une extension, de revenir en arrière des clés modifiées en dernier par l'extension à désinstaller. Mais bon, est-ce que cette méthode serait efficace et sans effet pervers...

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Ubiquity/0.1.3rc6

[jpj]

Et pourquoi personne réponds à Zerflng?

Son intervention n'est pas honteuse et est très (im)pertinente

Que veux-tu que l'on réponde. On peut pinailler en disant que le prefs.js, c'est quelques dizaines de Ko de fichier texte et quelques centaines de lignes facile à nettoyer à la main contre plus de 10 Mo d'un machin mal fichu, non éditable facilement et comportant des parties "secrètes" inaccessibles. Que la BDR affecte tout le système et les logiciels installés et que c'est autrement plus grave. Que c'est nettement plus simple et rapide de refaire un profil Firefox qu'une session Windows.

Que, que, que, ... qu'elle a parfaitement raison car, sur le fond, c'est exactement le même problème.

[calimo]

Perso je verrai bien les modifs de l'about:config stockés dans une base et lors de la désinstall d'une extension, de revenir en arrière des clés modifiées en dernier par l'extension à désinstaller. Mais bon, est-ce que cette méthode serait efficace et sans effet pervers...

En cas de réinstallation de l'extension, les données seraient perdues. De toutes façons, certaines extensions modifient des préférences "natives" donc ce serait extrêmement difficile de cloisonner tout ça...

[teoli2003]

En cas de réinstallation de l'extension, les données seraient perdues.

Ben c'est le but.

De toutes façons, certaines extensions modifient des préférences "natives" donc ce serait extrêmement difficile de cloisonner tout ça...

D'où l'idée d'une base pour stocker les modifs sous forme de journal et pouvoir cloisonner.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Ubiquity/0.1.3rc6

[Fabrice.Tres.Net]

Il est difficile de cloisonner puisque certaines données sont croisées.

Le problème du profil est identique quelque soit l'application: comment revenir en arrière après la modification de paramètres et surtout la personnalisation poussée d'un logiciel.

La comparaison entre le profil et la base des registres est biaisée, puisque la base des registres stockent les informations d'applications multiples et différentes. Dans le cas de FF ou TB, seul une application est considérée.

Les profils rouillés n'affectent que ceux qui jouent trop avec les extensions, cela doit être une faible part des utilisateurs.

[calimo]

En cas de réinstallation de l'extension, les données seraient perdues.

Ben c'est le but.

Mais il n'est pas bon. Quand tu désinstalles Firefox, ton profil est conservé. Il n'y a pas de raison que ce soit différent pour les extensions...

De toutes façons, certaines extensions modifient des préférences "natives" donc ce serait extrêmement difficile de cloisonner tout ça...

D'où l'idée d'une base pour stocker les modifs sous forme de journal et pouvoir cloisonner.

Il est difficile de cloisonner puisque certaines données sont croisées.

Je vais prendre un exemple, TabMixPlus, qui permet, je crois, de modifier la préférence "cachée" browser.link.open_newwindow.restriction
Comment proposerais-tu de faire dans ce cas ? C'est facile de dire qu'il faut cloisonner, mais l'application me semble plus délicate

[Uther]

Je vais prendre un exemple, TabMixPlus, qui permet, je crois, de modifier la préférence "cachée" browser.link.open_newwindow.restriction
Comment proposerais-tu de faire dans ce cas ? C'est facile de dire qu'il faut cloisonner, mais l'application me semble plus délicate Clin d'oeil

Ca pourrait être faisable, si les valeurs modifiés par les extensions étaient notées comme telles. Ca nécessiterait certes de faire évoluer le système, mais je pense que c'est techniquement possible.

Mais il n'est pas bon. Quand tu désinstalles Firefox, ton profil est conservé. Il n'y a pas de raison que ce soit différent pour les extensions...

Suis-je le seul a penser que ce comportement n'est pas le meilleur ni celui que la majorité des utilisateurs attend? Pour moi une désinstallation normale devrait tout effacer. Idéalement elle proposerait si on souhaite effacer les profils ou non.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090123 Minefield/3.2a1pre

[Zefling]

Déjà Firefox à l'avantage d'avoir la valeur par défaut.

Par contre quand il y a trop d'extensions (c'est mon cas)... C'est le bordel pour retrouver quelque chose.

Pour certains raisons je préfère quand même la façon dont son générer les variable dans Opera. Je me demande si il y aura déjà pas une moyen de faire ça et regrouper les variables précise d'un extension dans un groupe. Avec des noms des variables compréhensible par le commun des mortels

Pour moi ça c'est plus parlant :
SVG > Rendering Quality
Saved Settings > Open Dir
Saved Settings > Save Dir

Par contre le problème d'Opera, c'est qu'il ne donne pas le nom de la variable en question, ce qui est un peu emmerdant pour les programmeurs d'extensions.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

[teoli2003]

Je vais prendre un exemple, TabMixPlus, qui permet, je crois, de modifier la préférence "cachée" browser.link.open_newwindow.restriction
Comment proposerais-tu de faire dans ce cas ? C'est facile de dire qu'il faut cloisonner, mais l'application me semble plus délicate

J'imagine une table à quatre colonnes (ordonnées):

id_extension (NULL si utilisateur lui-même), timestamp, clé, nouvelle valeur

Lorsqu'on enlève une extension, on prend toutes les valeurs qu'il a modifié et, pour chacune d'elle, si elle n'a pas été modifié par la suite par une autre extension (ou l'utilisateur lui-même), on la remet à la valeur précédente (ou par défaut s'il n'y en a pas).

Bien sûr, on perd les données spécifiques à l'extension. Mais bon.

A noter aussi que si on installe "à la main" une extension ou qu'on la désinstalle "à la main" (i.e. Firefox fermé) cela ne le ferait pas.

Je pense que le plus difficile dans tout cela c'est de savoir si une modification donnée est due à une extension ou pas.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Ubiquity/0.1.3rc6

[Fabrice.Tres.Net]

Je pense que les extensions devraient gérer le profil un peu comme les fichiers de démarrage (run level /etc/rc.d) sous Unix.
On aurait le profil par défaut, modifiable via le pref.js, puis un répertoire extension comprenant un fichier de préférences pour chaque extension. Lors de la suppression d'une extension on supprime le fichier.
Le seul point à prendre en compte serait l'ordre de chargement des fichiers d'extension!

[calimo]

Je pense que les extensions devraient gérer le profil un peu comme les fichiers de démarrage (run level /etc/rc.d) sous Unix.

J'allais justement mentionner que sous Linux, du moins sous Ubuntu (p.ext. Debian) avec Synaptic, on peut choisir de désinstaller un paquet, ou de le désinstaller complètement, auquel cas les fichiers de configuration (dans /etc) sont également supprimés. Mais en aucun cas le profil utilisateur !

Sous Windows, je ne connais aucun logiciel qui désinstalle le profil utilisateur lorsqu'on le désinstalle. Ne faudrait-il pas plutôt prendre le problème à l'envers et mieux apprendre à l'utilisateur ce qu'est un profil de préférences (pas spécifiquement pour Firefox) (pas évident dans le monde windows où préférences et fichiers du programme ont très longtemps - et sont toujours ? - peu clairement séparés).

[teoli2003]

Résumé de l'état du développement de Firefox 3.2.

Nom: ni le nom de code (je parie pour un parc naturel en Afrique), ni même le nom final (Fx 3.2 ou Fx 4) ne sont décidés.

Planning: aucun planning n'est disponible pour l'instant

Nouveautés déjà disponible dans les nocturnes (qui ne sont pas dans Fx 3.1):
Interface Graphique

• Ctrl-Tab par Dão Gottwald, l'intéraction n'est pas définitive

Intégration dans l'OS

• Support du menu Services sous Mac OS

Layout

• Détection de la pression d'un clic pour les écrans tactiles (http://dougt.wordpress.com/2008/12/10/m ... n-mozilla/)
• SMIL; désactivé par défaut (et tout n'est pas encore implémenté, mais +2 ACID3), y compris:
  - SVGAnimationElement ( Bug 473702 ),
  - l'erratum de la norme SVG 1.1 qui uniformise SVG et SVG SMIL ( Bug 474257 ) et
  - SVGAnimateTransform( Bug 468996 ).
• Le support de l'unité CSS3 "rem" (root em):1 rem = 1 unité de la taille de police de l'élément root) (bug 472195, plus d'infos: http://xph.us/2009/02/02/rem-in-firefox.html ).

Javascript

• Bug 347174 : implémentation de document.readystate == "complete".
• Bug 123836 : implémentation de .indeterminate property sur les checkboxes et radio buttons.

Divers

• Suppression du code de migration 1.0->1.5; les profils 1.0 ne pourront être migré parfaitement (les extensions désactivées seront réactivées, si elles sont compatibles!)

Fonctionnalités prévues mais non réalisées
Interface Graphique

• Transformer la barre d'onglet en vraie barre d'outil (Dão Gottwald)

Layout

• SVG fonts, 3 points ACID3 (Robert O'Callahan, http://weblogs.mozillazine.org/roc/arch ... updat.html )
• SVG images (Robert O'Callahan, http://weblogs.mozillazine.org/roc/arch ... updat.html )
• Réécriture du code gérant le focus (Neil Deakin, http://www.xulplanet.com/ndeakin/item/19 - bug 178324)
• Robert O'Callahan décrit pas mal de modifs sans éléments visibles pour l'utilisateur mais qui rend le code plus simple et donc plus facile à maintenir: http://weblogs.mozillazine.org/roc/arch ... plans.html
• Suite du SMIL (Le meta-bug est Bug 216462 ), en particulier
  - Bug 436276 : animation des font-size (Seules les longueurs peuvent être animées pour l'instant);
  - Bug 436296 : animation des color;
  - Bug 436418 : implémentation de AnimateMotion;
  - Bug 474049 : support pour l'animation des propriétés CSS.

Javascript

• Ajout du tracing dans les regexp
• Ajout du tracing dans les appels récursifs

Intégration dans l'OS

• Même si ce n'est pas encore officiel, je serais surpris de ne pas voir le support des JumpList et des TaskBar Thumbnail de Windows 7.

Divers

• Sous Windows XP/Vista/Seven, support de la Text Services Framework ( Bug 88831 ) qui est prête et permettra une meilleure intégration avec les Tablet PC et de nombreux programmes extérieurs. Cela fut développé l'été dernier mais fut prêt trop tard pour Fx 3.1

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Ubiquity/0.1.3rc6

[Magmatik]

Merci pour cet état des lieux !

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090126 Minefield/3.2a1pre

[teoli2003]

Le bug 454184 a été corrigé; désormais les résultats de la fonction js eval sont cachés. Cela améliore un des tests de Sunspider mais aussi dans les webappl (Google Docs).

Ce fut d'abord implémenté par V8, puis par Webkit et maintenant TraceMonkey.

Pas encore sur si cela sera pris dans Fx 3.1 ou non. A suivre.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6