Julien Wajsberg a écrit 493 commentaires

Je suis plutôt d'accord avec toi. J'ai toujours trouvé ça perturbant d'avoir 3 exécutables différents au même endroit. Surtout que souvent exécuter l'un ou l'autre ne changeait pas grand chose… (mais sans doute quelque chose parce que sinon pourquoi en avoir 3? Bref.)

Plus les .so exécutables, ça fait pas sérieux.

Il faudrait ouvrir un bug ;) idéalement "firefox" devrait être tout seul dans son répertoire, avec un sous-répertoire "binaries" ou je ne sais quoi où mettre tout le reste.

3615 ma vie: moi j'utilise le .tar.gz officiel car ainsi j'ai toujours la dernière version, surtout sur une Debian Stable ;) L'ESR c'est bien gentil mais bon.

Reste à rendre la fonctionnalité compréhensible et utilisable (un peu comme le mode privé sauf que c'était plus simple).

Oui c'est le problème principal à résoudre. Car en fait la fonctionnalité était accessible depuis un bout de temps (cf l'add-on priv8 par exemple: https://addons.mozilla.org/en-US/firefox/addon/priv8/) mais l'UX est difficile à définir.

Tu parles de l'explication qui se trouve sur https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-protection-work ?

Je pense, oui. (Après, je ne suis pas dans le projet, je dis peut-être n'importe quoi :) )

Bonne nouvelle, Mozilla a donné 25000$ à 1. Et du coup le bug [3] sur Bugzilla a été rouvert le mois dernier :)

Tu peux contribuer à [1] peut-être ? ;)

[1] https://www.getdnsapi.net/
[2] https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-385000-to-open-source-projects-as-part-of-moss-mission-partners-program/
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=672600

En fait, il y a certes quelques extensions qui sont utilisées par beaucoup de monde, mais celles-ci sont pour la plupart déjà compatibles.

Le problème concerne plutôt les nombreuses extensions utilisées par juste quelques personnes qui ne peuvent pas vivre sans. C'est pourquoi l'introduction d'e10s est très très progressif pour pouvoir petit à petit réparer les problèmes de ces extensions sans perdre des utilisateurs qui perdraient leurs extensions.

Je vais juste répondre sur ta première question: Firefox OS (pour sa partie gonk) a toujours utilisé la partie bas-niveau d'Android: noyau Linux, modules noyaux spécifiques Android, démons provenant d'Android. Donc pas de changement ici.

Le changement concerne l'étape au-dessus. Dans Firefox OS, Gecko appelait directement les démons bas-niveau et les modules noyaux; par exemple pour afficher des pixels très rapidement. C'est ça que l'équipe se propose de changer en prenant le runtime dalvik (et ses classes standard donc) pour faire cela, comme sur un Android.

Normalement ça utilise speechd…

C'est assez étonnant, Firefox est censé être beaucoup moins gourmand que Chrome avec beaucoup d'onglets.

Pour ce qui est de la réactivité, j'ai déjà remarqué qu'une page gourmande en puissance avait tendance à ralentir d'autres pages, car il y a pour l'instant toujours le partage d'un process pour toutes les pages. C'est peut-être ton souci mais on y travaille.

Si tu as des problèmes, l'idéal reste de remonter un bug sur bugzilla.
Et peut-être vérifier si tu as les mêmes soucis dans Nightly avant :)

Il faudrait vérifier si c'est propre à la version packagée dans Ubuntu.

En fait, il me semble qu'il y a une erreur dans la dépêche: je crois que ce changement est pour MacOS X seulement. Windows et Linux avaient déjà ce comportement.

"toutes" tu y vas fort. Par exemple le mode lecture où se trouve la synthèse vocale est bien là. La nouvelle UX pour la recherche est toujours là aussi. Il y a aussi du boulot sur la gestion des bookmarks qui va rester.

Bref, tu es bien négatif. Ça me semble une bonne direction que de virer les trucs qui étaient bien en tant que logiciel à part mais bof dans un navigateur (Pocket, Hello) et qui avaient plutôt eu du mauvais feedback. Au contraire les trucs centraux à la navigation Web vont rester.

Je crois que c'est très exagéré.

• DRM: gestion des droits électroniques. C'est pour protéger les droits d'auteur dans le monde numérique. Aucun rapport avec la choucroute.
• Informatique déloyale aka tivoïsation telle que l'a décrite Stallman: impossibilité totale d'exécuter du code non signé sur une machine. Ici Firefox t'empêche juste d'exécuter du code sur Firefox. Mais tu peux toujours exécuter des choses en dehors de Firefox. Peut-être le déplores-tu, mais ce n'est pas de la tivoïsation.

Tu compares un verrouillage total d'une machine avec le verrouillage d'extensions dans une application (note d'ailleurs que Firefox ne t'empêche pas d'aller sur le site que tu souhaites sur Internet…). C'est je crois un contre-sens.

Il pourrait être possible de faire comme dans le Web: tester les APIs disponibles pour changer le comportement de l'extension.

Combien d'onglets as-tu ? J'ai un souci similaire même avec une disposition horizontale dès que j'ai beaucoup (quelques centaines) d'onglets.

SpeechRecognition semble supporté depuis Firefox 44 (d'après le lien MDN que tu as mis toi-même) ?

Il y a eu un gros changement d'architecture: les applications de type "certifié" qui avaient besoin d'API disponibles uniquement à ces applications ont été migrées dans un contexte plus privilégié (qu'on appelle un contexte "chrome"). Ça inclut donc l'application Système principale, le Homescreen, l'application Settings, l'application Clavier (je crois, pas certain), et donc l'application téléphone.

Ça a aussi nécessité la réécriture (ou du moins un changement dans l'exposition) des APIs en question.

Voilà pourquoi.

Je n'ai pas l'explication profonde de ce changement cependant.

C'est pas encore demain que le support XUL/XPCOM s'arrêtera, tu as un peu de répit.

Elles ne sont pas transparentes mais ont néanmoins le même look qu'ailleurs dans le système (notamment beaucoup plus minces).

Je sais qu'il y a un truc pour les rendre transparentes (càd visibles uniquement au scroll) car c'était utilisé dans Firefox OS mais je ne retrouve plus. Peut-être était-ce hard-codé pour Firefox OS.

Je ne comprends pas ce que tu veux, si une extension t'apporte déjà la fonctionnalité ?

Oui sémantiquement ça doit plutôt être ça :) Mais ce que je veux dire c'est que WebAssembly va venir à côté de ceux-là (dans SpiderMonkey il porte le joli nom de BaldrMonkey).

Note: TraceMonkey et JägerMonkey n'existent plus aujourd'hui. On a:

• un interpréteur qui n'a pas de nom particulier
• Baseline compiler: un premier optimiseur qui va venir cacher du code exécuté souvent
• IonMonkey: l'optimizing JIT.
• OdinMonkey: spécifique asm.js, ça joue le rôle de "raccourci" vers IonMonkey.
• BaldrMonkey: spécifique WebAssembly, il saute notamment l'étape de parsing.

Dans le futur, ils veulent modifier des ordres pour rendre le démarrage plus rapide pour asm.js et WebASM, car IonMonkey est assez lent à compiler (c'est pour ça qu'il y a des trucs avant d'ailleurs, pour ne pas le déclencher systématiquement).

Quel est le problème avec les magasins en ligne ? Ça existe déjà de toute manière (cf Steam), ce ne serait qu'un canal de plus…

Je n'en ai pas souvenir… peut-être une extension ?