Firefox 35, le navigateur web libre et ouvert de la fondation Mozilla, est sorti le 13 janvier 2015, pour GNU/Linux, Android (et Windows et Mac OS X). Cette version apporte son lot d’améliorations, notamment sur la sécurité, le Javascript, le CSS, le nouveau système de visioconférence Hello et sur l'utilisation du gestionnaire de téléchargements sous Android.
Cette dépêche régulière est le travail de nombreux contributeurs sur l'espace de rédaction de LinuxFr.org (linuxfr.org/redaction). Venez apporter vos contributions, afin que l'on puisse atteindre la qualité des dépêches noyau, par exemple.
Sommaire
Changements généraux
Sécurité
Lors de l’accès à un site par connexion chiffrée (HTTPS), il est possible de faire une attaque de l'homme du milieu, ou MIM pour Man In the Middle, en utilisant un certificat valide chez une autre autorité de certification.
Firefox vérifiait déjà, depuis la version 32 sur desktop et 34 sur mobile, si le certificat venait de la bonne autorité de certification, mais uniquement d’après une liste établie à l’avance de quelques gros sites (ceux épinglés par Chrome et ceux de Mozilla, puis Tor et Dropbox).
Or, on peut indiquer dans un entête HTTP (HTTP Public Key Pinning, épinglage de clé public HTTP) l’autorité de certification qui produit les certificats valides du site. Firefox prend désormais en compte cet entête pour empêcher la connexion s’il détecte un certificat non-conforme à ce qui est indiqué par l’entête. Voir le brouillon de la RFC de l'IETF pour les plus courageux.
L’entête peut toujours être modifié par un attaquant lors de la première visite, mais cela augmente grandement la sécurité.
Performances
Quelques changements sont à souligner :
- Amélioration de la gestion des modifications de style dynamiques (ex : animations CSS ou modification du CSS via Javascript) pour améliorer la réactivité ;
- Réduction de l’utilisation de ressources pour les images redimensionnées ;
- Utilisation du rendu par tuile sur Mac OS X. Son utilisation sur Android avait déjà montré de bien meilleures performances.
Pour les développeurs
Pour une liste complète des changements, voir le wiki de Mozilla pour les développeurs.
CSS
Les filtres CSS sont activés par défaut. Les filtres CSS permettent d’appliquer un changement avant que la ressource ne soit affichée, c’est notamment utile pour appliquer un effet à des images. Voir le wiki de Mozilla pour les développeurs pour plus d’informations.
Prise en charge de l'inspection des pseudo éléménts ::before et ::after.
Javascript
Côté Javascript, plusieurs changements :
- Implémentation de Resource Timing API, pour collecter des infos de délais des ressources à partir de JS ;
- Implémentation de l’API CSS Font Loading pour mieux maitriser le comportement du CSS lors du téléchargement de polices ;
- WebSocket est désormais disponible dans les Workers ;
- Changement de la sémantique de
leten Javascript pour correspondre à la spécification ES6.
Version Bureau
Firefox Hello
Firefox Hello fonctionne désormais par salon (chat rooms), qui persistent si un des deux utilisateurs part. Mais les salons semblent limités pour l’instant à deux personnes, pour tests initiaux. Gageons que l’on pourra bientôt organiser des réunions sur Firefox !
D’autre part, l’interface a été bien améliorée.
Vidéo
Avec cette version, Firefox étend le nombre de plate-formes supportant nativement le codec H.264. Cette fois-ci, c'est au tour de Mac OS X de prendre en charge ce codec vidéo, sur Snow Leopard (10.6) et supérieur.
Autre
- Firefox pouvait déjà afficher le flux d’actualité de certains réseaux sociaux dans une barre latérale. À cela s’ajoute un bouton «Partager cette page» dans la barre d’outils de Firefox et différents services (Facebook, Twitter, Google+, Delicious, Pocket, etc.) peuvent être ajoutés ;
- Un bouton «Application» a été ajouté dans le menu «Outils» de la barre de menu (si vous ne l’avez pas caché) et dans la liste des boutons à placer dans le menu personnalisation. Il permet d’accéder au Firefox Marketplace ;
- PDF.js a été mis à jour. De nombreux petits changements pour faire la mention de quelques uns. Nous vous invitons, pour les plus courageux, à lire la liste des changements.
Développeurs
De nombreux de petits changements sont à noter dans l’inspecteur :
- « Propriétés du DOM » maintenant présent dans le menu contextuel de l’inspecteur ;
- On peut maintenant inspecter les pseudos-éléments
::beforeet::after; - Onglet « Calculé » : survoler un sélecteur CSS surligne tous les nœuds qui correspondent ;
- Moniteur réseau : vues pour les entêtes des requêtes/réponses.
On note aussi la prise en charge de l’extension WebGL EXT_blend_minmax.
Version Mobile
De son côté, la version mobile n'est pas en reste :
- Amélioration du Mozilla's geolocation service (service de géolocalisation) en partageant les signaux Wi-fi et cellulaires. Activez cette fonctionnalité en ouvrant le menu Paramètres, section « Données collectées », paramètre « Service de localisation de Mozilla » ;
- Les recherches via Bing se font maintenant en HTTPS ;
- Boîte de recherche ajoutée aux pages d’erreur réseau ;
- Utilisation du gestionnaire de téléchargements d’Android ce qui permet de voir aussi les téléchargements de Firefox dans l’application « Téléchargements » d’Android et le sélecteur de fichier.
Le breton et l’espéranto ont été ajoutés à la version mobile.
Un bug est connu pour Android 5.0 (Lollipop) qui empêche la lecture des fichiers MP3 depuis Firefox.
Versions suivantes
Pour Firefox 36, à ne pas confondre avec la version 3.6, avant-dernière version avant le passage au cycle rapide, nous verrons ces améliorations :
- Les tuiles épinglées sur la page de nouvel onglet peuvent être synchronisées ;
- Beaucoup de progrès HTML5.
Firefox 37 se concentrera sur le CSS et le Javascript.
Aller plus loin
- Firefox (378 clics)
- Firefox 35.0 Bureau (208 clics)
- Firefox 35.0 Mobile (87 clics)
- Dépêche de la version précédente (50 clics)
# l'integration des nouveautés
Posté par walker17x . Évalué à 2.
cela fait bien des version que firefox nightly gère complètement html5 sur les video et sur youtube , mais je comprend pas pourquoi ils l'ont toujours pas intégré dans la branche stable
[^] # Re: l'integration des nouveautés
Posté par Sylvestre Ledru (site web personnel) . Évalué à 4.
Parce que c'était pas finalisé… C'est actuallement dans 36 beta et les développeurs continuent à corriger des bugs…
[^] # Re: l'integration des nouveautés
Posté par romu . Évalué à 4.
J'avoue ne pas comprendre ton message, c'est une vraie interrogation pour moi, pas un troll ok !
Mais, j'utilise html5 sur YouTube avec Firefox depuis des années. Alors, qu'entends tu exactement par gestion complète par les versions nightly ?
Merci.
[^] # Re: l'integration des nouveautés
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 15 janvier 2015 à 10:18.
Il suffit de regarder la page de test de Youtube : https://www.youtube.com/html5 .
Rien en rouge chez toi? Chez moi si (la deuxième ligne)
lien
[^] # Re: l'integration des nouveautés
Posté par StyMaar . Évalué à 8.
Jusqu'à présent Firefox gère uniquement la balise vidéo en progressive download en HTML5. Tu passes une url de vidéo à ta balise vidéo et le navigateur se charge de la télécharger progressivement et de la lire.
Ce qui arrive bientôt (version 37 probablement) c'est MediaSource Extention, une API HTML5 qui permet de jouer la vidéo en JavaScript : tu peux ajouter toi même des segments de vidéo en cours de route. Ça permet notamment de gérer les flux de streaming adaptatifs (MPEG DASH, HLS, Smooth Streaming).
Sur la Nightly c'est activé par défaut, mais c'est encore pas mal bogué
[^] # Re: l'integration des nouveautés
Posté par nicofrand . Évalué à 1.
Ils demandent également un peu d'aide en ce qui concerne les tests : https://oneanddone.mozilla.org/en-US/tasks/89/.
[^] # Re: l'integration des nouveautés
Posté par Antoine . Évalué à 9.
L'idéal ce serait qu'une entreprise, une fondation ou un truc équivalent puisse payer des gens à temps plein pour aider le développement de Firefox.
[^] # Re: l'integration des nouveautés
Posté par floriang . Évalué à -2.
Ça existe déjà : ça s'appelle Mozilla… ;-)
[^] # Re: l'integration des nouveautés
Posté par Sufflope (site web personnel) . Évalué à 6.
C'est triste ton avis sur l'ironie.
# HPKP mais pas DANE ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Donc ils ont mis en œuvre un système d'épinglage de clefs qui est à l'état de brouillon. En revanche, le système plus général et plus sûr DANE, qui lui n'est pas à l'état de brouillon mais bien publié, toujours pas ?
[^] # Re: HPKP mais pas DANE ?
Posté par autra . Évalué à 5.
Salut Tanguy (tu vas bien ?)
https://blog.mozilla.org/security/2014/09/02/public-key-pinning/
Dans les commentaires, un gars donne une explication :
« DANE has some attractive qualities, but there are a number of technical hurdles to overcome in order to implement it. For example, many network devices still prevent DNSSEC from working correctly. »
Mais, la vrai raison, c'est sûrement que c'est pas prêt un point c'est tout. Le bug : https://bugzilla.mozilla.org/show_bug.cgi?id=672600 et ya même déjà un patch.
[^] # Re: HPKP mais pas DANE ?
Posté par dyno partouzeur du centre . Évalué à 0.
Accessoirement, HTTP Public Key Pinning doit marcher assez mal avec le mode "navigation privée" je suppose, parceque sinon ça veut dire que firefox garde une trace rémanente des sites visités qui ont une clé fixée. Du coup on est obligé de renoncer à la sécurité du mode navigation privée pour profiter de la feature.
A moins qu'une clé qui a été récupérée en mode public puisse s'appliquer quand on surfe en mode privé, du coup il faudrait visiter le site au moins une fois en mode normal avant.
[^] # Re: HPKP mais pas DANE ?
Posté par ariasuni . Évalué à 2.
J’imagine que ça fonctionne comme pour le cache (je crois que le mode de navigation privé peut utiliser le cache principal de Firefox).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: HPKP mais pas DANE ?
Posté par aurel (site web personnel, Mastodon) . Évalué à 1.
D'ailleurs, la prise en charge du HPKP me laisse perplexe pour l'instant. J'ai faits des tests après avoir configuré un site test avec les instructions disponibles ici. Que l'empreinte soit absente, présente correcte ou présente incorrecte, Firefox 35 ne me signale rien du tout (testé sur Arch et MacOS).
Est-ce que l'un de vous sait comment tester s'il fonctionne ?
# Pour rester dans les départements...
Posté par IckyThump . Évalué à 10.
Firefox 35, il est vilain !
[^] # Re: Pour rester dans les départements...
Posté par Adrien . Évalué à 1.
Ah, il est pas brésilien ? :)
[^] # Re: Pour rester dans les départements...
Posté par Adrien . Évalué à 10.
pardon, je m'emporte, j'aurais du dire « Breizh’iliens »
# Boîte de recherche tout cassée...
Posté par jihele . Évalué à 4.
Je vais encore faire le râleur… La boîte de recherche a été refondue et elle est devenue inutilisable au clavier. Est-ce qu'il y a une façon de la paramétrer pour que ce soit comme avent ?
Avant je faisais
Maintenant, je ne sais plus faire sans la souris.
C'est une action que j'exécute à longueur de journée…
[^] # Re: Boîte de recherche tout cassée...
Posté par Albert_ . Évalué à 5.
continue a utiliser les fleches cela te fais arriver aux moteurs et la tu continue encore avec les fleches haut/bas (pas droite gauche meme si c'est horizontal…) pour aller sur le moteur voulu
[^] # Re: Boîte de recherche tout cassée...
Posté par jihele . Évalué à 2.
Ah oui ! En effet, en appuyant sur "haut", on remonte directement dans les moteurs. Au final, c'est peut-être encore plus pratique. Moins rapide pour aller au 2ème moteur mais immédiat pour aller au dernier. Et ça éviterait le bordel des fois où je me retrouvais par accident à sélectionner des mots auto-suggérés au lieu de changer de moteur.
Peut-être qu'à l'usage je m'y ferai.
Merci pour l'info.
[^] # Re: Boîte de recherche tout cassée...
Posté par Sufflope (site web personnel) . Évalué à 10.
Passer de « bordel ils ont tout pété ces cons » à « c'est peut-être encore plus pratique » en un message. Tellement beau que t'en chiales.
[^] # Re: Boîte de recherche tout cassée...
Posté par jihele . Évalué à 3.
J'ai pas tenu, j'ai mis browser.search.showOneOffButtons à False aussi…
C'était assez lent. Peut-être parce que pour pouvoir changer de moteur, il fallait attendre que la liste des auto-suggestions soit chargée.
[^] # Re: Boîte de recherche tout cassée...
Posté par Sufflope (site web personnel) . Évalué à 2.
Je vais battre un peu ma coulpe : autant sur Fx34/OSX quand j'avais eu cette nouvelle recherche automatiquement activée sur le MBP du boulot, elle m'était apparue pas mal, parce que forcément j'ai toujours l'excellent pavé tactile sous les doigts même quand je tape au clavier, autant sur mon fixe (maintenant que Fx35 l'a activée partout), où c'est plus de mouvements pour repasser sur la souris, elle commence déjà à me casser sévèrement les gonades.
[^] # Re: Boîte de recherche tout cassée...
Posté par pdm . Évalué à 3.
Pas sûr que ça suffise : je suis revenu à l'ancien mode en passant browser.search.showOneOffButtons à false
# Et quid du portage gtk3 ?
Posté par Dams Nadé (site web personnel) . Évalué à 3.
Ca se stabilise ? Wayland arrivant, ca me paraissait vaguement important.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . Évalué à 3.
Ne serait-il pas plus pertinent de ne plus avoir de Xul/Gtk3/Gtk2 ni Xul/Cocoa ni Xul/(Windows je ne sais quoi), en utilisant une interface web dans gecko lui même, par exemple : browser.html
Parce que quand on a sous la main un moteur de rendu web, qui sera de toute façon lancé, la nécessité d'utiliser/se trimbaler/maintenir un toolkit est tout de même discutable.
[^] # Re: Et quid du portage gtk3 ?
Posté par lolop (site web personnel) . Évalué à 2.
Tu peux nous expliquer comment tu fais pour faire les tracés graphiques sans avoir à un moment accès à une API graphique via un toolkit quelconque (à part bien sûr en tapant directement dans les API natives des plateformes… ce qui nécessite de faire une couche intermédiaire, genre toolkit, pour s'adapter à chaque plateforme).
Parce que le moteur de rendu html, faut bien qu'à un moment il aille faire dessiner des pixels par la carte graphique.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Et quid du portage gtk3 ?
Posté par Larry Cow . Évalué à 5.
Je crois que ce qu'il voulait dire, c'était qu'avoir une couche intermédiaire qui sait dessiner des boutons, quand ton moteur de rendu web sait le faire de toutes façons, c'est un peu overkill. Et qu'il suffit, dans ce cas, d'avoir une abstraction dessinatoire de base, plutôt qu'un plein toolkit.
En gros, SDL plutôt que CeGUI. Ou Gdk/Cairo plutôt que tout Gtk.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . Évalué à 2.
Pour dessiner une page Firefox utilise principalement Mozilla-Azure, qui lui même a plusieurs backend (ha j'ai trouvé ça pour dégrossir le terrain). :
- Direct2/3D (Windows),
- Quartz/Coregraphique (OSX),
- OpenGL/Cairo (Linux)
A partir de là, je pense qu'un toolkit (Xul compris) est superflu et que c'est à Gecko/Servo d'avoir des backends qui utilisent soit OpenGl/Cairo, soit Wayland/X11/Mir directement.
Comme le fait blender en utilisant de l'OpenGL pour son interface : puisque de toute façon ce logiciel implémente un rendu OpenGL et que celui-ci sera forcément lancé, on peut utiliser OpenGL partout.
Pour Firefox, mon raisonnement est le même : on a un moteur html qui est lancé, pourquoi ne pas l'utiliser partout.
Et je pense que c'est l'idée du dev mozilla à l'origine de browser.html, puisque son objectif est de ne plus avoir besoin de Xul (Xul qui est utilisé actuellement comme surcouche à Gtk2/3, cocoa, windows).
petite réflexion (mais arrêtez moi si je dis des âneries) :
- Gtk3 utilise cairo comme backend
- Gecko utilise Cairo comme failsafe backend (si il n'y a pas OpenGL)
Donc si on fait un portage Gtk3 de firefox on se retrouvera avec des cas où firefox fera appel à cairo pour dessiner la page, puis à Xul qui sous linux fera appel à Gtk3 (pour les éléments genre boutons) qui fera lui même appel à cairo pour faire ce rendu.
[^] # Re: Et quid du portage gtk3 ?
Posté par StyMaar . Évalué à 0.
D'après ce que j'avais compris c'est plutôt l'inverse. On peut utiliser openGL sous Linux, mais c'est désactivé par défaut.
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
C'est exactement l'idée qu'ont eu les développeurs quand ils ont crée Gecko : utiliser le moteur de rendu pour l'interface utilisateur (1998). D'où le XUL (un langage XML + js pour le comportement + CSS pour l'apparence). Je pense qu'à l'époque, ils n'ont pas utilisé le HTML parce qu'il était très basique, cela aurait nécessité de trop gros changement dans le HTML et le CSS (trop de balises et styles propriétaires) : d'où un nouveau langage. De plus le XUL a des fonctionnalités très spécifiques comme les overlays, l'usage des DTD pour les traductions et bien d'autres choses.
Bref, on a un moteur qui sait prendre n'importe quel langage XML et HTML, et sait l'afficher en le stylant en CSS.
browser.html, c'est très bien, mais ils manquent encore des choses en HTML pour faire tout ce qu'on peut faire en XUL, pour qu'il remplace ce bon cher browser.xul.
Et puis abandonner XUL, cela voudrait dire abandonner une grosse majorité des extensions… XUL va disparaitre, mais c'est pas pour demain. Il y a énormément de boulot.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . Évalué à 2.
Je comprends bien que XUL à été le HTML++ de Mozilla et qu'il est impossible de l'abandonner facilement. Mais il me semble possible de le marquer comme "déprécié" et le but de mozilla-Jetpack était de le remplacer et le rendre totalement obsolète il me semble.
Bref de n'utiliser XUL que pour les extension qui n'ont pas été mise à jour, dans la même idée de rétrocompatibilité Wayland/Mir avec X11. Car c'est un peu ça : XUL est le X11 de Mozilla.
Alors que Mozilla est en train de construire un OS et toute son interface en HTML/JS/CSS, ça me semblerai être un sacré échec de ne pas pouvoir utiliser HTML5 pour implémenter les quelques controls/boite de dialogues de Firefox en HTML/JS/CSS.
Et d’ailleurs que manquerai-t-il à HTML5 ? (c'est une vrai question, car techniquement : avec l'usage du Shadow Dom j'avais compris que l'on pouvait construire un composant web de toute pièce et le rendre réutilisable, bref on construit son toolkit en web)
Là on est d'accord : il y a beaucoup de boulot. Donc pourquoi perdre son temps à faire évoluer un toolkit (Gtk2 vers Gtk3) alors que le but est de normaliser la pile graphique.
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Ce n'est pas implémenter des boites de dialogues qui posent problème, c'est tout ce qu'il y a dans un navigateur.
browser.html, ce n'est pas un fichier html que l'on va mettre dans firefox en remplacement de XUL, et qui va tourner en mode privilégié comme le XUL. browser.html est une webapp. qui tourne donc dans une sandbox.
Du coup, comment dans l'interface on affiche par exemple l'historique de navigation (pour le gestionnaire de l'historique) ? comment accéder à la liste des mots de passe (pour le dialog de gestion des mots de passe) ? Comment modifier les préférences (pour une bonne partie des paramètres de la boite de préférences) ? Il y a aussi la gestion des "commandes" de l'interface, la gestion du copier coller, la gestion de la fenetre etc…
Bref, un navigateur, ce n'est pas juste afficher une page web, c'est aussi est surtout pouvoir gérer plein de truc autour. Et pour cela, il faut utiliser des API interne. Chose facile quand on est en XUL, parce que le code JS/XUL de Firefox (et celui des extensions XUL) tourne en mode privilégié (le mode chrome), et donc on peut appeler n'importe quel composant interne XPCOM.
Et le souci ici est que l'interface de browser.html, comme toutes les webapps, comme toutes les applis de FirefoxOS, tournent dans une sandbox. Pas d’accès direct à ces composants internes.
Il faut donc exposer, dans le contexte HTML, des API qui permettent de pouvoir faire ce qu'on pouvait faire en mode chrome.
Ces API étant souvent "sensibles", il y a un système de permissions.
Un exemple d'API, c'est l'api de navigation. Ça l'air con de gérer des onglets et la navigation : suffit de gérer des iframes, et dans chaque iframe, tu charges un site. Oui mais pas seulement. Comment surveiller l'état du chargement d'une iframe, afin de pouvoir afficher un throbber dans la barre d'url ? Comment stopper le chargement d'une iframe ? comment detecter justement que l'iframe démarre le chargement d'une nouvelle page, pour mettre à jour l'url dans la barre d'url ? Comment récupérer les informations sur le certificat SSL du site chargé afin de pouvoir les afficher quand on clique sur le cadenas ? etc etc etc… En mode chrome, aucun souci. Mais quand tu es dans une page HTML qui n'a pas les privilèges chrome, t'es à poil. En html standard, tu n'as pas d'API pour tout ça.
Il faut donc développer ces API (qui, techniquement, à leur tour, appellerons les apis interne de gecko). Tu as un début avec la browser API, mais ce n'est pas suffisant. Il faut une API pour accéder au contenu de l'historique complet, une API pour accéder aux certificats, et des centaines d'autres API. Et créer/gérer les permissions qui vont avec.
Bref, il y a encore beaucoup, beaucoup de boulot. C'est d'ailleurs la raison pour laquelle le "navigateur" dans FirefoxOS est encore si pauvre en fonctionnalité.
D'ailleurs, tu remarqueras que pour faire les trucs de bases (copy/paste/undo/redo) de browser.html, tout ça est géré dans un fichier XUL lancé en mode chrome.
Note: il y a eu le même problème pour les extensions de type jetpack (non xul donc), qui tournent dans une sandbox JS. Il a fallu exposer dans cette sandbox un certain nombre d'API pour accéder aux API internes de Gecko. Et implémenter tout ça ne s'est pas fait en un jour (raison pour laquelle on a encore accès à un module "chrome" pour accéder directement aux composants internes).
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . Évalué à 1.
Merci, c'est beaucoup plus clair.
J'avais déjà vu la Browser API, mais je me rendais pas compte de tous ce qu'il y manquait.
Donc en gros : y a encore beaucoup de travail, mais lorsque Gecko aura les API nécessaires (historique, navigation, certificats, …), et lorsque ce sera finalisé : le navigateur de FirefoxOS (qui lui n'utilise pas XUL) sera complet et rien n'empêchera de faire un Firefox Desktop avec browser.html ou équivalent.
J'ai bon ?
PS: Grâce à cette discussion je viens de découvrir SlimerJS. Je ne savais même pas que ce genre d'outil existait, faudra que je test à l'occasion pour les units test dans au moins 1 projet. Donc encore une fois merci
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
tout à fait.
Qui plus est, si ces API sont standardisées (ce qui est le but ultime de mozilla), que le format "webapp" est lui aussi standardisé, et tout ça implémenté dans d'autres moteurs, on pourrait imaginer à terme lancer notre browser.html avec blink ou webkit par exemple.
Mais il y a encore beaucoup de chemin à parcourir, malgré que l'on puisse dés aujourd'hui lancer une webapp indifféremment avec Firefox desktop, Firefox pour Android ou encore FirefoxOS (sauf si ladite appli utilise les api de téléphonie par exemple : ça va moins bien fonctionner sur le desktop :-)).
De rien :-)
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Euh… Non…
Gtk ne sert pas qu'au XUL. Je dirais même, pas trop à XUL. Conçernant XUL, GTK sert juste à savoir des infos comme les couleurs systèmes, accéder aux fontes système etc. XUL, ce n'est que du HTML++ : tout est stylé en CSS. Il est vrai aussi que XUL s'appuie sur le toolkit (gtk, cocoa ou Windows) pour dessiner les boutons et quelques autres trucs d'interfaces. Et tu sais quoi ? c'est dessiné en indiquant la propriété CSS appearance. Qui sert aussi en HTML puisque cette propriété était prévu dans la spec css3-ui et reportée dans css4, mais cela n’empêche pas qu'elle soit implémentée dans Firefox et Webkit.
La présence de GTK/Cairo/Windows est surtout là pour gérer les fenêtres, ouvrir les boites de dialogues de fichier, d'impression etc du système, accéder au presse papier et de beaucoup d'autres choses.
Bref, XUL ou HTML, un navigateur a besoin d'un toolkit comme gtk et autre, en plus d'une lib purement graphique.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . Évalué à 2.
Peut être que je ne me rend pas compte mais j'ai l'impression que Gtk n'est utilisé que pour quelque trucs accessoires : aller lire la config système (couleur/font etc) et la boite dialogue système d'impression (sur ce dernier point Chrome m'ouvre sa boite de dialogue, faite en web je suppose).
Je comprend très bien qu'il soit plus rapide à court terme d'utiliser Gtk, mais je trouve que c'est beaucoup un toolkit tout entier* pour juste quelque actions qui pourrait être remplacés par un code plus beaucoup plus simple.
*: (et à fortiori un Gtk3 qui va embarquer son propre Cairo en plus de celui déjà présent dans Mozilla-Azure)
Je trouverai dommage que beaucoup d'heure de R&D soient utilisées à passer de Gtk2 à Gtk3 (puisque ça fait longtemps qu'on a parle c'est que ça doit pas être simple ce portage) alors qu'elles pourraient être employées sur Mozilla-Azure + browser.html pour mettre au point une interface qui serait utile à toute les plate-forme Win/OSX/Linux-Gtk-Qt et pourquoi pas même android etc.
[^] # Re: Et quid du portage gtk3 ?
Posté par Ytterbium . Évalué à 2.
Oui, mais peut-être que les utilisateurs apprécient d'utiliser des applications intégrées à leur desktop. Déjà que les applications GNOME font n'importe quoi, je n'ai pas envie d'avoir un firefox d'un autre style que celui de mon bureau. D'ailleurs, c'est aussi pour ça que je n'aime Chromium.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . Évalué à 1.
Il est vrai que d'avoir des applications toute dépareillés n'est pas du plus bel effet.
Cela dit ce qu'il y a de beaux avec une application web c'est qu'en changeant de CSS ont peut s'adapter au look de l'OS (c'est ce que fait Qt avec son propre gestionnaire de style très inspiré de CSS).
Sur ce point Chrome et Gtk* sont des mauvais exemples puisque l'un ne reprend pas la charte graphique de l'OS et l'autre s'accorde très mal avec KDE.
*: donc par extension Firefox sous linux/KDE est un mauvais exemple d'intégration.
[^] # Re: Et quid du portage gtk3 ?
Posté par pascalc . Évalué à 5.
La migration à GTK3 est prise en charge majoritairement par des employés de Redhat et de Collabora, s'ils ne travaillaient pas sur ce portage, ils travailleraient sur d'autres projets de leurs boîtes et pas sur du Firefox, il n'y a donc pas de perte de ressources chez Mozilla pour autre chose.
Le bug de suivi pour le portage vers gtk3 est celui-là : https://bugzilla.mozilla.org/show_bug.cgi?id=627699
À ma connaissance, Mozilla n'embarque pas Cairo, il utilise le Cairo du système sous Linux donc je ne pense pas non plus que ce point porterait problème (Mozilla est aussi un des contributeurs code historiques à Cairo).
Personnellement, j'aimerais que Firefox soit encore mieux intégré à Linux, même si son intégration est déjà pas mal, surtout par rapport à Chrome. Par exemple, j'ai un nouveau portable avec une résolution type retina et les navigateurs (ainsi que des applis comme Atom basée sur Webkit) ne suivent pas le scaling système. Pour Chromium c'est juste inutilisable, je lis à peine les titres sur les onglets par exemple. Pour Firefox et Thunderbird, au moins il y a une option pour changer l'échelle du rendu html (et donc d'une grosse partie de l'UI) c'est layout.css.devPixelsPerPx que je mets à 1.20, mais si Firefox était encore mieux intégré au système, il pourrait aller chercher cette info tout seul plutôt que j'aie à la changer dans about:config. Il me semble que le support des écrans HiDPI sous Gnome sera vraiment pris en charge correctement via gtk3/Wayland donc pour moi c'est un bon exemple de ce qu'apporte le portage vers gtk3.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . Évalué à 0.
C'est sympa de la part de RedHat et de Collabora de
collaborercontribuer.En fait je me référais à ces explications, et c'était ce que je comprenais de :
Mais ces explications semble ne plus être d'actualité, et en cherchant un peu il apparaît que tu as raison : Cairo est une dépendance, donc Mozilla-Azure n'embarque pas ou plus son propre Cairo.
(et je note au passage qu'il y a maintenant un backend Skia, l'équivalent de Cairo utilisé par Chrome)
Je rejoins ton avis sur la non intégration de chromium à l'OS, et sa mauvaise gestion des écrans haute résolution sous Linux. Moi perso avec Firefox je configure la police système en plus gros : ça s'applique sur les barres de titres et onglets et après dans Firefox je vais dans préférence->contenu augmenter la police.
Là je ne vois pas en quoi un toolkit tout entier est nécessaire pour aller chercher une info système. Et la gestion du HiDPI c'est hyper simple à faire en web (depuis le temps que tous le monde fait du responsive design).
Mozilla développe et maintient son toolkit web (Gecko) avec son moteur de dessin (Azure) qui est multiplate-forme, qui dispose de plusieurs backend etc. Gtk fait beaucoup doublon au milieux de tout ça.
L'interface de Firefox OS est géré entièrement par cette pile graphique (Gecko/Azure) alors il doit pas manquer grand chose pour gérer entièrement celle de Firefox Desktop.
[^] # Re: Et quid du portage gtk3 ?
Posté par StyMaar . Évalué à 1.
Si j'ai bien compris, le rendu de Firefox sous GNU/Linux utilise massivement des hacks de X11, du coup passer à GTK3 ne changera pas grand chose au problème. (dsl, j'ai pas de source pour étayer mon propos vu que je tiens ça d'une discussion orale)
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . Évalué à 1.
Effectivement d'après ceci, le problème est double : si Mozilla veut passer à Wayland/Mir en continuant de s'appuyer sur Gtk il faut :
1. passer de Gtk2 à Gtk3 (nécessaire pour Wayland), ne pose pas de problème à Gecko en lui même mais en pose tous plein pour les plugins (comme flash) faisant des appels à Gtk2
2. enlever+remplacer dans le code tout les appels spécifique à X11
Je penses que les dev Mozilla savent ce qu'ils font mais j'ai l'impression que maintenant que le web (HTML5) est un outil pouvant remplacer un toolkit, on pourrait en profiter pour remplacer Gtk.
# v36 = Beaucoup de progrès HTML5 = support de html5 dateTime ?
Posté par trancheX . Évalué à 3.
Loin de moi l'envie de répéter les critiques des commentaires sur firefox 34.
C'est super de voir Firefox avancer et tenir tête à des géants comme Google/Microsoft/Apple dans la guerre des navigateurs.
Je suis persuadé que des projets comme Rust et servo ou browser.html représentent l'avenir et je suis très content que Mozilla soit l'acteur qui actuellement prend les engagements techniques les plus audacieux.
… Mais est-il prévu que l'amélioration du HTML5 de la future version 36 nous fasse profiter des éléments date-time ?
Car le non-support de cet élément dans firefox est une vrai plaie pour les développeurs web.
Bref est ce que quelqu'un a repris la suite des travaux de Mounir Lamouri sur les webForms ? Et si non est ce que quelqu'un est capable de me dire quel sont les éléments HTML5 à implémenter de manière prioritaire pour Mozilla ? et est-il possible de voter/influencer ces choix ?
Note: je sais que la critique est facile et qu'on va me dire que rien ne me m'empêche de l'implémenter moi même.
A cela je dirai que mon manque de compétences et de temps ne me permette pas d'effectuer cette tache, par contre j'ai l'impression que Mozilla regorge de javascript-ninjas, et qu'il suffirait qu'un seul décide de finir ce travail pour que ce soit fait dans la prochaine version de firefox.
[^] # Re: v36 = Beaucoup de progrès HTML5 = support de html5 dateTime ?
Posté par barmic . Évalué à 6.
Non, la liste des fonctionnalités de la prochaine version de Firefox est déjà fixée et ne bougera pas (c'est ce que tu trouve dans l'actuel beta).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: v36 = Beaucoup de progrès HTML5 = support de html5 dateTime ?
Posté par trancheX . Évalué à 1.
Dommage, et pour la v37 non plus apparement
PS: désolé pour le double post, si un admin peut effacer celui qui est inutile, merci par avance
[^] # Re: v36 = Beaucoup de progrès HTML5 = support de html5 dateTime ?
Posté par Porkepix . Évalué à 1.
Et que sauf grosse bêtise de ma part, on touche ici à tout ce qui lit, comprends, et rend ton contenu web. Et en l'état, ce ne serait pas du Javascript…mais plutôt du C++.
[^] # Re: v36 = Beaucoup de progrès HTML5 = support de html5 dateTime ?
Posté par trancheX . Évalué à 1.
Je pensais que comme une date n'est qu'une string formaté d'une certaine manière du point de gecko, alors le moteur C++ n'avait pas besoin d'être touché.
Je penses que ce qu'il manque c'est une implémentation javascript/HTML du sélecteur de date en utilisant du shadow DOM (comme pour les élément range input, video etc) qui fasse la transformation en une string au format date en proposant à l'utilisateur une interface conviviale.
Mais j'ai peut être mal compris le fonctionnement de ces inputs, et du moteur de rendu web.
# Commentaire supprimé
Posté par trancheX . Évalué à -1. Dernière modification le 16 janvier 2015 à 13:31.
Ce commentaire a été supprimé par l’équipe de modération.
# Privacy for you™
Posté par Le Gab . Évalué à 2.
https://www.mozilla.org/fr/privacy/you/
Si c'est vrai, pourquoi des modules comme Ghostery, AdBlock+ et consorts ne sont-ils pas fournis de bases et fonctionnerait sur un modèle d'opt-out dans ce cas-ci?
Cette schizophrénie me dérange. On sait que les sites n'honorent pas le don't track me et que c'est une idée stupide de base.
[^] # Re: Privacy for you™
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Ghostery ? le truc qui, si tu fais pas gaffe, envoi tout ce qu'il bloque à la société qui le développe, pour ensuite… revendre ces données aux sociétés de pub/tracker &co ?
Adblock+, qui a lui aussi un drôle business model ?
Je ne pense pas que ce soit une bonne idée pour Mozilla de les inclure de base… (même si je les utilise tous les deux)
Bon, on pourrait imaginer qu'ils développent ou choisissent une solution plus éthique, mais cela pose d'autres problèmes :
[^] # Re: Privacy for you™
Posté par woprandi . Évalué à 3.
Disconnect au lieu de ghostery
[^] # Re: Privacy for you™
Posté par ariasuni . Évalué à 4.
Ou Adblock Edge avec (au moins) EasyList+List FR, EasyPrivacy, Fanboy’s Social Blocking List.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Privacy for you™
Posté par Porkepix . Évalué à 1.
Ou Privacy Badger, proposé par l'EFF.
Perso je les cumule, histoire d'être sûr de son coup, malgré la lourdeur que ça implique.
# Barre de titre
Posté par woprandi . Évalué à -1.
Pourquoi la barre de titre et d'onglets ne sont toujours pas fusionnées contrairement à Windows/OSX ? Est-ce prévu à terme ?
[^] # Re: Barre de titre
Posté par Kioob (site web personnel) . Évalué à 0.
À moins que je confonde avec une autre fonctionnalité, c'est le cas depuis longtemps, mais pas actif par défaut sous Linux : suffit de décocher «Barre de menus» dans «Affichage → Barre d'outils».
alf.life
[^] # Re: Barre de titre
Posté par woprandi . Évalué à 2.
Barre de menu != Barre de titre
# Doublons CA
Posté par Thomas M . Évalué à 1.
Du coup me vient une question : est-ce que les autorités de certification ont un mécanisme pour empêcher/détecter la création d'un certificat pour un domaine déjà géré par une autre autorité ?
Si je trouve un moyen de contourner les mécanismes de vérification à la création d'un certificat, je peux obtenir un certificat valide pour n'importe quel domaine déjà pris en charge ailleurs ?
[^] # Re: Doublons CA
Posté par gouttegd . Évalué à 2.
Empêcher, non.
Détecter, pour l’instant, non plus. Google a proposé Certificate Transparency qui pourrait servir à ça. En gros, cela suppose que tous les certificats émis par les CAs sont enregistrés dans un ou plusieurs « journaux de certificats » (certificate log) publiquement consultables par quiconque, ce qui pourrait permettre à une CA de vérifier, avant d’émettre un certificat, si une autre CA n’a pas déjà émis un certificat pour le même domaine. Mais rien n’oblige les CA à faire cette vérification et à ma connaissance, aucune n’a annoncé qu’elle allait le faire.
(Ce n’est pas, à l’origine, le but de Certificate Transparency. La grande idée derrière CT est que les CAs malhonnêtes (rogue CA) n’oseront pas soumettre leurs certificats aux journaux de peur de voir leurs magouilles exposées au grand jour. Conséquement, tous les certificats non enregistrés dans un journal seront suspects.)
Oui. Le système de PKIX implique de faire confiance, non pas seulement à la CA qui a émis un certificat pour un domaine donné, mais à toutes les CA dites « de confiance » (celles qui sont présentes par défaut dans le magasin des navigateurs), ainsi qu’à leurs innombrables sous-CA pour faire bonne mesure.
# Firefox hello et ToxBox.com
Posté par JGO . Évalué à 3.
Quelqu'un pourrait-il expliquer la relation entre Firefox Hello et ToxBox™®© ?
[^] # Re: Firefox hello et ToxBox.com
Posté par Larry Cow . Évalué à 5.
Si j'ai tout compris, la partie "signaling" (i.e. pas la communication effective entre les navigateurs, juste la mise en relation) passe par le service de ToxBox. Qui a l'air libre et hébergeable ailleurs, mais je n'ai pas l'impression que Mozilla l'ai fait.
[^] # Re: Firefox hello et ToxBox.com
Posté par JGO . Évalué à 2.
Merci pour la réponse. J'ai trouvé leur billet WebRTC and Signaling: What Two Years Has Taught Us Ils expliquent qu'ils ont essayé SIP et XMMP et que les limites intrinsèques et les performances étaient insuffisantes, et qu'ils ont donc développé leur propre protocole. On peut ne pas être d'accord mais au moins c'est clairement expliqué. cela dit c'est dommage que Mozilla redirige une partie du trafic des utilisateurs vers des serveurs tiers.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.