Firefox 6: Rumeurs et news sur le développement

[teoli2003]

Avec l'accélération graphique Direct2D/DirectWrite sous Vista/Win7, certaines personnes n'étaient pas satisfaites de la qualité du rendu. Il est désormais possible d'adapter le rendu ClearType pour Firefox au moyen des préférences suivantes:

Une valeur négative indique d'utiliser les defauts du système (ou de ClearType Tuner).

• gfx.font_rendering.cleartype_params.gamma, valeur par défaut: -1
  GammaLevel * 1000, typical values 1000-2200 (1.0-2.2):
• gfx.font_rendering.cleartype_params.enhanced_contrast, valeur par défaut: -1
  EnhancedContrast * 100 (percentage)
• gfx.font_rendering.cleartype_params.cleartype_level, valeur par défaut: -1
  ClearTypeLevel * 100 (percentage)
• gfx.font_rendering.cleartype_params.pixel_geometry, valeur par défaut: -1
  PixelGeometry: 0 = flat, 1 = RGB, 2 = BGR
• gfx.font_rendering.cleartype_params.rendering_mode, valeur par défaut: -1
  ClearTypeMode: 0 = default, 1 = aliased, 2 = GDI Classic, 3 = GDI Natural, 4 = Natural, 5 = Natural Symmetric

La dernière, gfx.font_rendering.cleartype_params.rendering_mode avec la valeur 2 (GDI Classic) semble particulièrement appréciée de ceux qui avaient des problèmes de qualité.
C'est un mini-projet de l'équipe GFX, appelé Text Rasterization Options.

[Zefling]

Dommage que ça soit pas plus accessible, parce que peut de monde sait que le about:config existe et comment l'utiliser (ça semble aussi nébuleux que le registre de Windows...)

En fait il manque un truc comme ça par défaut : http://guiconfig.freedig.org/ (propriétés avancées..)

[teoli2003]

En fait, à la base, ces paramètres sont une expérience qui permettent à ceux qui se plaignent de jouer avec ceux-ci et de rapporter leur ressenti en fonction des paramètres. L'analyse de se retour permettra éventuellement de choisir d'autres valeurs par défaut (éventuellement en fonction de la config).

L'idée reste quand même que ce soit bon par défaut chez (presque) tous.

À noter qu'avec ces paramètres, il est désormais trivial d'adapter gui:config...

[Zefling]

À noter qu'avec ces paramètres, il est désormais trivial d'adapter gui:config...

Je suppose que c'est ce qu'ils feront.

[teoli2003]

Au premier trimestre 2010, un projet avait été lancé pour améliorer la réactivité en diminuant les E/S du fil principal d'au moins 50%.

7-8 modifications ont été alors identifiées pour une diminution d'environ 60 %. Deux ne furent pas faites durant ce premier trimestre, qui atteint 42 % de réduction. L'une des deux améliorations fut terminée en décembre, assez tôt pour Firefox 4.

Quant à la dernière, l'écriture asynchrone des méta-data dans le cache disque, comptant pour 6-7 % des E/S sur le fil principal au début 2010 (et probablement autour de 15 % aujourd'hui) a été terminée la semaine dernière.

Je m'attendais à ne rien ressentir au niveau de la réactivité, mais, effet placebo ou non, j'ai l'impression que de passer d'un onglet à l'autre est plus rapide depuis cette modification. Mais c'est peut-être juste un effet placebo, même si l'amélioration est réelle et bien sûr bienvenue.

À noter que plus votre disque est lent, plus l'effet positif se sent. Il est donc miminum pour un SSD et maximum sur un téléphone mobile.

[teoli2003]

Un autre mozillacisme a été supprimé (en fait un bug signalé en 2001).

Gecko acceptait un attribut maxwidth — taille en pixels du contrôle — sur <input type="text">. Cela n'existait dans aucune norme HTML et était en fait un héritage involontaire de XUL.

Cela n'existera plus dans Firefox 6

Mozilla obeys invalid maxwidth attribute on text form controls

[teoli2003]

Bon, ben du moment que je parle de mozillacismes (Geckismes me paraît mieux sonner — hop! je l'adopte... ).

Les propriétés document.height et document.width ont vécu et ne font plus rien. S'ils sont utilisés désormais, un message d'avertissement est noté dans la console d'erreurs:

• Non-standard document.width was used. Use standard document.body.clientWidth instead.
• Non-standard document.height was used. Use standard document.body.clientHeight instead.

(Tiens, je ne sais pas si ce genre de messages sont localisés. Je pense que oui, mais vous les avez sûrement compris en vo sans les sous-titres.)

Le bug: remove document.height / document.width

[teoli2003]

Les deux propriétés text-decoration-style et text-decoration-color avaient été implémentées, préfixées par -moz, d'abord pour Firefox 5. Mais comme elles ne s'intégraient pas bien avec le raccourci existent, text-decoration, elles avaient été retirées d'Aurora (mais laissée dans Nightly pour Firefox 6).

Les deux bugs bloquants ont été corrigés:

• Bug 647421 -moz-text-decoration-color and -moz-text-decoration-style should be reset by text-decoration
• Bug 648299 -moz-text-decoration-style: -moz-none; does paint the decoration lines

Je pense désormais qu'il est fort probable que cela survive au passage de Fx 6 à Aurora dans 4 semaines.

[teoli2003]

À l'époque de CSS 2 (donc bien avant CSS 2.1), un essai avait eu lieu avec les Aural Style Sheet, une extension au CSS permettant de contrôler la manière dont une page web étaient rendue sur un media de type aural.

Cela n'a jamais pris et aujourd'hui c'est le module CSS3 Speech qui a pris le relais. Il n'est pas encore implémenter mais Aural Style Sheet n'ont plus. En fait seul le parsing CSS de ses propriétés spécifiques étaient dans Firefox.

Comme ce sont les seules propriétés accessibles mais non implémentées, comme Aural Style Sheet c'est du passé, comme CSS3 Speech utilise pour l'essentiel des propriétés différentes, comme cela rend la détection du support d'une fonctionnalité plus dure, ce support vient d'être retiré du parseur.

Donc n'espérez plus accéder aux valeurs de: azimuth, cue, cueAfter, cueBefore, elevation, pause, pauseAfter, pauseBefore, pitch, pitchRange, richness, speak, speakHeader, speakNumeral, speakPunctuation, speechRate, stress, voiceFamily et volume.

Cela ne devrait pas nous empêcher de dormir.

Bug 649119 — Remove parsing and storage of CSS 2.0 aural style sheet properties

[teoli2003]

Chaque navigateur implémente un mode quirks qui permet d'avoir une soupe de tags à peu près digeste à l'écran.

Ce sont une collection de comportements déviants du standard qui fait que le web marche plus ou moins.

Avec le temps, le comportement des navigateurs se modifient et se diversifient et certains de ces quirks ne sont plus nécessaires et même les brasseurs de soupe n'utilisent plus d'aussi mauvais ingrédients. Ainsi depuis 2003 et Mozilla 1.3, l'idiome CSS .class:hover était ignoré (en mode quirks seulement). Comme la plupart des navigateurs n'ont plus cette règle exceptionnelle aujourd'hui, ce comportement a été supprimé.

Ainsi désormais, en mode quirks, la pseudo-classe :hover marche avec les liens, les images, les champs de formulaires ainsi qu'avec tout sélecteur qui comprends des noms de balises, des id, des attributs ou (nouveau) des classes.

Quand on vous dit de coder selon les standards, c'est pour éviter d'entrer dans un mode quirks qui se comportera différemment d'un navigateur à l'autre.

Bug 197686 — :hover (dynamic pseudo-class) doesn't work after class selectors with no tag name in quirks mode

[Zefling]

Ils continuent de virer tout ce qui sert plus à rien : Remove WinCE code from mobile/components/build/

[teoli2003]

L'équipe Gfx (Graphics) a plein de projets en cours! Difficile de savoir lesquels seront fait en premier, mais je vais vous présenter les principaux (suivez le lien pour avoir la liste exhaustive, assez technique néanmoins).

• Text Rasterization Options. Je vous en ai parlé lorsque c'est arrivé sur Nightly il y a quelques jours. Il s'agit de quelques options pour configurer le rendu de Direct2D/DirectWrite sous Windows Vista et 7.
• NPAPI Async Drawing Extension. Flash 10.2 (version IE) et IE9 utilisent une nouvelle API pour plus de performances. L'idée est d'étendre l'interface NPAPI (Netscape Plugin API) de Firefox pour permettre le même genre d'optimisation. Le bug. L'API.
• Electrolysis Accelerated Layers. C'est la grosse étape pour Electrolysis (en numéronyme e10s), le projet de dissocier Firefox en différent processus (pour augmenter la résistance au crash et donc la stabilité. En effet, il s'avère que profiter de l'accélération GPU n'est pas trivial lorsque plusieurs processus doivent écrire dans la même fenêtre... Prévue pour Firefox 7 (vers octobre), il s'agit de permettre d'utiliser les layers en IPC (Interprocess communication).
• La première étape du projet Azure, projet à long terme consistant à remplacer Cairo par quelque chose de plus flexible et efficace, en particulier en ce qui concerne les besoins e10s, sera l'utilisation de l'accélération GPU pour le Canvas 2D.
• CSS3 3D-Transforms. Y compris l'accélération par le GPU. Le bug.
• Accélération matérielle (GPU) pour Fennec.
• Antialiasing pour WebGL. Amélioration du rendu du WebGL grâce à l'antialiasing

C'est sûrement pas exhaustif, mais ce sont ceux où cela à l'air de bouger le plus.

[teoli2003]

Même si le soucis de la compatibilité des extensions revient, tel le serpent de mer, à la sortie de chaque nouvelle version de Firefox, la gêne occasionnée n'était que passagère avec une périodicité de 12 à 18 mois.

Mais avec une nouvelle version toutes les 6 semaines, et avec l'abandon immédiat du support pour les versions précédentes, cette gêne se transforme en véritable problème. En effet, même si l'Addon API (anciennement Jetpack), qui ne souffre pas du problème de compatibilité ascendante, s'améliore régulièrement, cela va forcer les développeurs d'extension à tenir un rythme d'enfer. Un tel rythme est déjà un sacré challenge pour le grand Mozilla, alors le petit développeur besogneux, chez lui, le soir après le taf, aura de la peine à maintenir ses quelques extensions.

Aussi, un plan a été élaboré.

Tadaa!

Il s'agit d'ajouter à AMO un testeur automatisé d'extension, via des houpaloumpas au service du bon fonctionnement de la chocolaterie des concepteurs d'extensions. Toute extension douteuse (dans le sens où son comportement pourrait se trouver altéré dans la nouvelle version), ne verra pas son numéro de version bumpée lors du passage d'un cycle à l'étape Aurora. Un courriel est envoyé au développeur. Mais pour les autres, bump automatique! Et hop, dès Aurora, beaucoup d'extensions seront déjà compatibles.

Bien sûr, il y aura des erreurs, mais les phases Aurora et Beta devraient permettre de les repérer. Quant aux extensions loin d'AMO, et bien, vae victis.

Le détail: http://blog.mozilla.com/addons/2011/04/ ... -releases/

et une image honteusement piquée dans l'article:

[julroy67]

C'est quand même bon signe qu'ils aient pensé à changer ça un peu, sinon les utilisateurs non expérimentés allaient se retrouver à nu très souvent

Cependant, comme donné, pour les nightly users au fond, ça change rien, faudra continuer comme avant donc.

[teoli2003]

Cependant, comme donné, pour les nightly users au fond, ça change rien, faudra continuer comme avant donc.

Nightly n'est plus recommandé pour des utilisateurs. Seuls les développeurs et les "hardcore users" doivent les utiliser. Des 38000 utilisateurs actuels, 2/3 devraient migrer vers Aurora.

J'ai déjà migré quelques connaissances.

Et comme ce n'est plus recommandé, aucun simplification d'utilisation ne sera fait. (Encore que j'ai toujours mes extensions sur Nightly, à chaque bump de version, j'ai une clé dans le about:config a ajouté et zou!)