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 (61)
#1
Ah super.
Enfin ,ils s’y mettent.
ce soir ,je fais la maj (ou la réinstall) ,cool ^^.
#2
la taille de la pile, qui ne devrait normalement pas dépasser les 512 Mo, peut grimper jusqu’à 2 Go
#3
”-…, ils appelles pour dire que le Titanic vient d’arriver.
" />
-Vaut mieux tard que jamais.”
#4
Il serait temps !
#5
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 ?
#6
“Segment Overflow Windows error ”
" />
#7
Ha ! Encore un pas dans le nouveau millénaire ! :p
#8
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.
#9
J’aurais plutôt dis “NotImplementedException”
" />
#10
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 )
#11
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.
#12
“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.
#13
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.”
#14
#15
ENFIN
#16
Et le lien vers la v37 bêta :
https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/37.0b2-candidates/bui…
#17
Ca marche très bien depuis un moment
" />
#18
Chuck norris viens d’affirmer sur twitter qu’il possédait firefox 42 en 64 bits (stable)
#19
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
#20
#21
#22
#23
#24
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+.
#25
#26
Ah je les retrouvé:
https://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/#mem
#27
“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.
#28
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.
#29
#30
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.
#31
#32
Le permettre de changer les touches ?
" />
#33
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.
#34
#35
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.
#36
#37
#38
#39
Au bureau, je manque parfois de mémoire(j’ai coupé le swap), et Firefox se fige.
#40
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.
#41
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.
#42
#43
Pour compléter la réponse de CryoGen
#44
#45
#46
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 !
#47
#48
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.
#49
Il était temps, ça fait un peu 15 ans que les processeurs 64 bits sont dans les PCs grand publics.
#50
#51
#52
… ???? 
" />
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?
#53
#54