Geckozone

J'ai un problème sur Gmail avec Minefield, il m'est impossible d'ajouter une pièce jointe, après avoir choisi mon fichier et validé, il ne se passe rien, le fichier ne s'upload pas. Ca vous le fait aussi ?

edit: ça marche très bien avec FF 3.0.6

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090227 Minefield/3.2a1pre

Ce n'est pas une histoire d'extensions ? Parfois ça me le fait sans que je sache pourquoi. Il faut savoir que depuis quelques jours c'est du Flash qui gère l'upload de fichier sur Gmail, ça vient peut-être de là.

Message envoyé avec : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090226 Shiretoko/3.1b3pre

Toto a écrit :Il faut savoir que depuis quelques jours c'est du Flash qui gère l'upload de fichier sur Gmail, ça vient peut-être de là.

Oh la loose !!!!!! Je viens de tester ça, t'as effectivement raison. :/

quelle est la solution? j'ai le meme probleme? hors ca marche nikel sous safari


PS : j'ai shockwave flash 10.0.22.87


edit : https://bugzilla.mozilla.org/show_bug.cgi?id=480430

Message envoyé avec : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090227 Shiretoko/3.1b3pre

Ca n'est pas corrigé dans la dernière nightly.

D'où l'intérêt d'avoir un petit Firefox portable stable sur une clé USB pour ce genre de petites choses .

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090302 Minefield/3.2a1pre

Tiens, le bug m'a permis de voir qu'on peut désactiver le Flash et remplacer ça par le réglage ancien. Ouf !

SMIL compilé par défaut, mais désactivé via la préférence "svg.smil.enabled", sur le trunk.
Vous pouvez commencer à tester l'implémentation en passant la préférence à true (ce qui permet d'atteindre 96 à l'acid3)

Je pose une question qui n’a rien à voir avec la discussion en cours (comme d’hab, diraient les mauvaises langues) : y a-t’il un benchmark pour comparer le temps que mettent les différents moteurs (gecko, webkit, trident, opera) pour le rendu d’une page ouèbe ?
On lit souvent que gecko est lent, qu’en est-il réellement, est-ce que ça peut se chiffrer ? Et est-ce qu’on peut mesurer l’évolution des perfs de Gecko au fil des version ?

Parmi les nombreuses métriques, les perfs de chargements de page sont suivi. Je ne sais plus quel est le protocole de test exact.
Par contre, il sert surtout à vérifier en continue les non régression, pas tellement à comparer les versions (machines différentes)
(je sens que ce lien va foirer)
http://graphs-new.mozilla.org/graph.html

Personnelemt je ne pens pas que Gecko soit lent.
Mais que XUL le soit, c'est une certitude.

Lance Camino sur un page d'accueil et lance Firefox sur la même page d'accueil. Il y a une différence indéniable.
Par contre une fois chargé, il me semble que l'affichage des pages sous FF est plutot rapide.
D'ou le sentiment que ce soit XUL le boulet, pas Gecko.

Ayé, je viens de retrouver ce que je cherchais, la source était tout simplement sur le site Apple : http://www.apple.com/befr/pr/press/2009 ... fari4.html

Safari [4] charge les pages web HTML trois fois plus vite que IE 7 et près de trois fois plus vite que Firefox 3. (*)
(*) […] Test de performances HTML basé sur iBench version 5.0 de VeriTest avec les réglages par défaut.

Y a-t’il d’autres benchmarks de ce type ? D’après 01Net, iBench favoriserait Safari et ne serait donc pas forcément pertinent…
Corollaire, un utilisateur Mac pourrait-il comparer les perfs HTML entre Firefox 3 / Safari 3 et Firefox 3.5b / Safari 4b ?

bobo a écrit :(je sens que ce lien va foirer)

Ça foire pas, mais ça fait bien pédaler le CPU. C’est un bon test JavaScript en soi !

Jim a écrit :Lance Camino sur un page d'accueil et lance Firefox sur la même page d'accueil. Il y a une différence indéniable.

L’interface en XUL augmente le temps de chargement, et est moins réactive qu’une interface native (du moins, sans le chrome-jit). C’est un fait.
Ma question ne porte que sur le temps de rendu d’une page, là où WebKit prétend mettre la pâtée à Gecko. Le test pertinent serait de comparer le temps que mettent les deux navigateurs pour ouvrir un nouvel onglet, par exemple.

Les tests SunSpider (javascript) et Acid3 (css) c’est bien joli, mais je trouve bizarre qu’on n’ait pas de tests équivalents pour le bête HTML. Peut-être parce que le temps de rendu HTML n’est pas significatif sur un PC de bureau moderne ? Pourtant, sur un terminal mobile (smartphone, tablette Nokia), je pense que ça fait une différence sensible.

Kazé a écrit :

bobo a écrit :(je sens que ce lien va foirer)

Ça foire pas, mais ça fait bien pédaler le CPU. C’est un bon test JavaScript en soi !

En fait, il avait fait foirer le forum (à cause des crochets dans l'url quand tu veux faire un lien direct vers une pré-sélection, vive phpbb !), mais je l'ai modifié ensuite.

Ah bah voilà pourquoi je n’accédais plus à cette page…
C’est le genre de trucs qui est bon à savoir quand on veut saboter un forum. ^^

Il semblerait qu'il y ait beaucoup de problème avec cette balise « url » ? Vire l'encodage URI.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7 (.NET CLR 3.5.30729)

Kazé a écrit :Corollaire, un utilisateur Mac pourrait-il comparer les perfs HTML entre Firefox 3 / Safari 3 et Firefox 3.5b / Safari 4b ?

Comment ? Dromaeo, Sunspider ? Peacekeeper ?

Message envoyé avec : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090312 Shiretoko/3.1b4pre