Mozilla publie une version 64 bits de son Firefox Developer Edition
Pour ceux qui aiment l'aventure, la vraie
Pour le dixième anniversaire de Firefox, Mozilla avait lancé une Developer Edition conçue pour faciliter le travail des créateurs de sites et d'applications web. Une version 64 bits pour Windows est maintenant disponible, débloquant un ensemble d’améliorations qui devraient permettre une hausse sensible des performances et une meilleure sécurité.
Un pas de plus vers une version 64 bits officielle de Firefox
Mozilla s’approche donc encore un peu plus d’une version 64 bits de Firefox pour Windows. Une telle mouture existe depuis longtemps dans les « Nightlies » mais n’est jamais entrée dans un canal officiel de test, qu’il s’agisse d’Aurora ou de la branche bêta. Cette nouvelle version permet aux développeurs de se pencher sur les améliorations spécifiques liées au 64 bits, et elles sont nombreuses.
Pour qui suit l’actualité des navigateurs, ces avantages sont déjà connus, qu’il s’agisse des performances ou de la sécurité. Pour cette dernière par exemple, l’ASLR (Address Space Layout Randomization) devient accessible. Rappelons que cette fonctionnalité permet de déplacer au hasard certaines données sensibles pour qu’elles ne puissent pas être trouvées par un malware de manière prévisible.
Un impact visible sur les performances, surtout pour le JavaScript
Du côté des performances, le 64 bits a évidemment un impact. Il débloque tout d’abord l’adressage au-delà des 4 Go, ce qui a une réelle importance quand on se place dans un contexte d’applications web lourdes, voire de jeux. Dans le cas d’un portage vers asm.js par exemple, Mozilla indique que la taille du tas (heap), qui ne devrait normalement pas dépasser les 512 Mo, peut grimper jusqu’à 2 Go. la protection matérielle de la mémoire permet en outre de se débarrasser de certaines opérations dans le traitement de JavaScript, accélérant encore la vitesse d’exécution du code.
Outre les améliorations spécifiques au 64 bits, cette nouvelle Developer Edition est basée sur ce qui deviendra Firefox 38. Parmi les apports, on notera l’arrivée de l’API BroadcastChannel, le support du KeyboardEvent.code, qui permet au développeur de savoir quelle touche d’un clavier est physiquement pressée sans en connaitre la disposition ou la possibilité de filtrer les requêtes XMLHttpRequests dans le moniteur réseau. On remarquera dans les notes de version que les sites n’auront également plus la possibilité de bloquer le remplissage automatique des champs consacrés aux identifiants.
Notez que, comme toute version issue du canal de développement Aurora, cette version de Firefox est susceptible de contenir des bugs et donc d’être instable. Les intéressés pourront la télécharger depuis l’un des liens ci-dessous :
Commentaires (54)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 04/03/2015 à 12h11
Le 04/03/2015 à 13h30
J’avoue que je ne comprends pas cette difficulté de passer au 64 bits :
Je n’ai jamais lu aucun code qui fasse de distinction entre 32 bits ou 64bits, mise à part justement lorsque l’on souhaite justement une variable de type entière ou à virgule flottante (double précision) à 64 bits. Et la encore les compilateurs 32 bits géraient la situation en toute transparence donc il n’y a pas de modification à apporter avec l’usage d’un compilateur 64 bits.
Alors effectivement si l’on fait du code pas très propre ou l’on stocke des pointeurs dans des int on peut avoir un soucis, et le portage s’impose (mais à voir si le compilateur n’adresse pas d’avertissement dans ce cas).
Tout ce que je vois sur la génération des binaires 64 bits :
Pour le premier point comme dit plus haut cela fait des années que les architectures 64 bits sont présentes.
Et pour le second, je ne vois pas pourquoi Mozilla jouerait à ce jeu.
Voilà si ce que je dis est bête je m’en excuse et prierai que l’on éclaire ma lanterne.
Le 04/03/2015 à 17h01
Il était temps, ça fait un peu 15 ans que les processeurs 64 bits sont dans les PCs grand publics.
Le 04/03/2015 à 17h05
Le 04/03/2015 à 17h11
Le 04/03/2015 à 18h42
… ???? 
" />
couper le swap… c’est pas le conseil qu’on pouvait trouver sur des sites internet à la con, censé augmenter les performances de windows du temps de windows 95 ???
qui peut croire encore à ça?
de plus, pourquoi est ce que windows aurait une mauvaise gestion de la mémoire?
Le 04/03/2015 à 20h13
Le 05/03/2015 à 08h24
Le 03/03/2015 à 14h53
Il serait temps !
Le 03/03/2015 à 14h56
Je ne comprends pas, ça fait pourtant des années (au moins depuis la démocratisation du 64bits avec l’AMD64) que Firefox est disponible en 64 bits sous Linux et intégré et mis à jour par toutes les distributions…
" />
Ils foutaient quoi sous Windows ?
Le 03/03/2015 à 14h59
“Segment Overflow Windows error ”
" />
Le 03/03/2015 à 15h11
Ha ! Encore un pas dans le nouveau millénaire ! :p
Le 03/03/2015 à 15h12
Principalement à cause des différences liées à gcc entre Linux et Windows, ainsi que des optimisations du 32bits pour Windows rarement compatible avec la nouvelle compilation pour 64bits et qu’ils avaient autres chose à faire qu’à réécrire la quasi-totalité du code dédié à Windows.
Ensuite il existe des versions compilées pour Windows x64 avec des patch et/ou glitch et qui est de plus en plus stable.
Le 03/03/2015 à 15h12
J’aurais plutôt dis “NotImplementedException”
" />
Le 03/03/2015 à 15h18
En fait, firefox x64 existe sous windows depuis la version 4 mais ils l’ont jamais sorti de nightly (https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/07/2010-07-31-04-mo… firefox-4.0b3pre.en-US.win64-x86_64.zip )
Le 03/03/2015 à 15h18
enfin ils s’y remette… depuis le temps que beaucoup de pc sont en 64bits et que Windows emule le 32 pour le faire fonctionner… menfin ce n’est pas le seul logiciel dans ce cas.
Le 03/03/2015 à 15h19
“Parmi les apports, on notera (…) le
support du KeyboardEvent.code, qui permet au développeur de savoir
quelle touche d’un clavier est physiquement pressée sans en connaitre la
disposition”
Et voilà le retour des jeux codés uniquement pour clavier qwerty et qui se retrouvent injouables en azerty.
Le 03/03/2015 à 15h41
Je comprends l’inverse, au lieu de renvoyer “z” ça devrait renvoyer le
“code” de la touche qui est standard quelque soit le modèle (azerty,
qwerty…).
“The KeyboardEvent.code property represents a physical key, that is value not changed neither by the modifier state, nor by keyboard layout.”
Le 03/03/2015 à 15h46
Le 03/03/2015 à 15h53
ENFIN
Le 03/03/2015 à 16h01
Et le lien vers la v37 bêta :
https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/37.0b2-candidates/bui…
Le 03/03/2015 à 16h08
Ca marche très bien depuis un moment
" />
Le 03/03/2015 à 16h13
Chuck norris viens d’affirmer sur twitter qu’il possédait firefox 42 en 64 bits (stable)
Le 03/03/2015 à 16h24
c’est la séparation des onglets en processus distincts qui commence à se faire salement attendre, la version amd64 je trouve pas ça fondamentalement utile actuellement
Le 03/03/2015 à 14h51
Ah super.
Enfin ,ils s’y mettent.
ce soir ,je fais la maj (ou la réinstall) ,cool ^^.
Le 03/03/2015 à 14h53
la taille de la pile, qui ne devrait normalement pas dépasser les 512 Mo, peut grimper jusqu’à 2 Go
Le 03/03/2015 à 14h53
”-…, ils appelles pour dire que le Titanic vient d’arriver.
" />
-Vaut mieux tard que jamais.”
Le 03/03/2015 à 21h15
Je ne sais pas, mais souvent les touches par défaut ne me vont pas… Parce que même si c’est un Azerty, il suffit qu’une touche ne soit pas comme sur le clavier des dévs pour que ça n’aille pas.
Le 03/03/2015 à 21h20
Le 03/03/2015 à 21h31
Dans le taskmanager, tu pourras tuer l’onglet qui part en vrille, qui ne veut pas s’arrêter ou qui bouffe toutes les ressources. C’est très pratique dans Chrome.
Le 03/03/2015 à 21h35
Le 03/03/2015 à 21h41
Le 03/03/2015 à 21h43
Le 03/03/2015 à 22h37
Au bureau, je manque parfois de mémoire(j’ai coupé le swap), et Firefox se fige.
Le 03/03/2015 à 23h06
Heu, coupé le swap quand on n’a pas assez de mémoire c’est un peu débile, surtout vu la gestion assez calamiteuse de Windows avec celle-ci.
Le 03/03/2015 à 23h22
Je ne vois pas de quoi tu parles. Plus de mémoire => allocation foirée, c’est au programme de gérer,
et non pas de compter sur le swap. Alors que Windows l’augmente bien gentiment.
EDIT: je coupe le swap pour économiser les disques.
Le 04/03/2015 à 04h24
Le 04/03/2015 à 08h29
Pour compléter la réponse de CryoGen
Le 04/03/2015 à 09h11
Le 04/03/2015 à 10h36
Le 04/03/2015 à 10h54
Tout à fait ! D’ailleurs, avec 16Gio de RAM chez moi, le swap par défaut, eh ben, il est toujours vide ce bougre donc n’use rien du tout !
Le 03/03/2015 à 16h35
Le 03/03/2015 à 16h38
Le 03/03/2015 à 16h44
Le 03/03/2015 à 16h55
Le 03/03/2015 à 17h13
Ca faisait 3 ans que j’avais la nightly x64 avec Flash sous Windows 2003 server…
jusqu’au jour où Mozilla a dit que le support était abandonné au profit de Vista+.
Le 03/03/2015 à 17h30
Le 03/03/2015 à 17h37
Ah je les retrouvé:
https://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/#mem
Le 03/03/2015 à 17h56
“autocomplete=off is no longer supported for username/password fields”
Pourquoi ceci? Je n’ai pas trouvé d’explication sur leur site. Et aussi comment FireFox détecte le champs “username”? Je n’aime pas la magie.
Le 03/03/2015 à 18h04
J’utilise FirefoxDeveloperEdition (64bits sous OS X depuis le debut) pour tester mes devs et j’ai pas compris l’intérêt de ce truc par rapport a un navigateur classique qui possède deja les outils de dev (sans compter les extensions).
Pire, comme FirefoxDeveloperEdition a une gueule un peu differente de Firefox, certaines extensions s’affichent mal (la toolbar de SEOQuake par exemple).
De plus ca se met a jour tous les jours ou presque ce qui est particulièrement relou et n’a aucun intérêt pour un dev web.
Quand je l’ai installe, je me suis dit que les dev tools allaient enfin etre au niveau de ceux de Chrome => absolument pas.
Conclusion : FirefoxDeveloperEdition n’a d’intérêt que le buzz que Mozilla peut en tirer. Ils auraient mieux fait de passer leur temps a autre chose.
Le 03/03/2015 à 18h14
Le 03/03/2015 à 18h20
Je pense que c’est pour laisser le choix à l’utilisateur, plutôt qu’aux sites web.
Ensuite pour la détection des champs : je suppose que dès qu’un formulaire a un champ type “password”, l’autre est déclaré “username” quand il n’y en a qu’un.
Le 03/03/2015 à 20h35
Le 03/03/2015 à 20h59
Le permettre de changer les touches ?
" />