Firefox 4 + Lorentz + Tumucumaque + Macaw: News sur le dév.

[teoli2003]

Pour info, même si c'est relativement calme ces jours-ci, il y a une grosse activité de stabilisation: corrections de crashs, de régression, de cas particuliers mal traités.

Enfin, plein de choses qui ne se voient pas mais qui sont importantes pour avoir une version 4 stable.

[Uther]

C'est sur que maintenant que la beta 7 (presque feature freeze) est sortie, tu risques d'être plus actif sur le sujet firefox.next.

[Zefling]

Pour la bêta 8, il y a bien deux changement prévu dans ce que j'ai vu :
- Combiner le bouton panorama et tab-list (bug 596017)
- Changement du thème Mac pour les onglets (bug 547787)

Après, il me semble que tout le reste ça restera invisible. La proportion de bugs critiques pour crash augmente.

[antistress]

make the download manager UI run inside a browser tab
http://home.kairo.at/blog/2010-11/jokul ... ad_manager

(en attendant Firefox 4+)

[teoli2003]

Voilà qui va faire plaisir à beaucoup de monde!

window.alert(), window.prompt() et window.confirm() seront modaux à l'onglet et non plus à la fenêtre, dès la prochaine nocturne.

Cela ne correspond pas encore à toutes les alertes (la fenêtre des mots de passe par exemple n'en fait pas partie), mais c'est un progrès significatif. Je pense pour ma part qu'il s'agit du problème d'UX le plus grave de Firefox (en fait surtout le problème des fenêtres de mots de passe): le voir s'en aller (même partiellement) est vraiment chouette.

Bug 59314 [Toolkit:General]-Alerts should be content-modal, not window-modal.

[Zefling]

Ça fait des années que j'espérais voir ce problème corrigé. Enfin un vieux bug de moins.

Dans les bugs qui ont dix ans, il resterait pour moi que : 2056, 33339, 39965 & 63687.

[teoli2003]

Dans les bug qui ont dix ans, il resterait pour moi que les bugs : 2056, 33339, 39965 & 63687.

Pour les deux premiers, il y a de grandes chances qu'ils soient corrigés dans Firefox.next (la spec de run-in a été précisée pour le passage en PR de CSS2.1 et le ruby c'est du HTML5). Pour la troisième, je sais pas; quant à la quatrième, avec l'arrivée de la HTML5 FileAPI et la Drag&Drop API, elle est contournable par n'importe quel site, et donc bien moins importante qu'il y a quelques années encore.

[Zefling]

C'est vrai, mais encore faut-il que tous les sites passes au HTML5. Parce que mine de rien, ça demande pas mal de boulot d'utiliser toutes ses nouveautés.
L'avantage du multi-file est tout de même que ça ne nécessite pas de JS.

J'espère que Ruby XHTML 1.1 n'est pas mis sur le carreau, je m'en sers pas mal. Et quand je vois ce que ça donne dans Firefox 4, c'est une vrai prise de tête pour faire un nouveau hack CSS. Certaines balises ne sont plus du tout reconnu de la même façon.

[teoli2003]

J'espère que Ruby XHTML 1.1 n'est pas mis sur le carreau, je m'en sers pas mal. Et quand je vois ce que ça donne dans Firefox 4, c'est une vrai prise de tête pour faire un nouveau hack CSS. Certaines balises ne sont plus du tout reconnu de la même façon.

Ben <rt> <rb> sont communs au Ruby XHTML 1.1 et au HTML5. <rp> n'existe plus (Je dis cela de tête). Mais de toutes manières les balises inconnues (c'est le cas des trois dans Firefox 4) devraient se comporter de la même manière dans Firefox 4 qu'auparavant, c'est à dire comme des HTMLUnknownElement, soit des <span> par défaut. Et ils devraient être stylables dans tous les navigateurs (sauf IE6/7/8 s'ils ne les supportent pas, sauf hack JS; IE9 permet de styler les éléments inconnus comme le demande la norme).

[Zefling]

Je ne constate pas trop la même chose :



Édit : je viens de comprendre, si je repasse en XHTML 1.1 ça passe bien, si je passe en (X)HTML 5 ça me donne ça.
Bref, si on utilise les ruby complexe, on peut dire adieu à HTML5. ( Super évolution )

[teoli2003]

Il faudrait contrôler ce que demande la norme pour le parser HTML5, au niveau du contenu des éléments inconnus (<rtc> ici) et si c'est faux, de le signaler dans bugzilla.

Edit:
La norme dit ceci:

A start tag whose tag name is one of: "rp", "rt"

If the stack of open elements has a ruby element in scope, then generate implied end tags.

En d'autres termes, lorsqu'il rencontre <rp> ou <rt> il doit fermer tout tag ouvert depuis le <ruby>, soit le <rtc>. Le comportement de Firefox 4 est donc conforme à HTML5.

A noter que <rtc> et <rtb> n'existent pas en HTML5.

Edit2:
Quoique, si je lis ceci (la définition de "generate implied end tags"):

When the steps below require the UA to generate implied end tags, then, while the current node is a dd element, a dt element, an li element, an option element, an optgroup element, a p element, an rp element, or an rt element, the UA must pop the current node off the stack of open elements.

Il ne devrait pas fermer <rtc>. Cela pourrait bien être un bug dans le parser HTML5 de Firefox.

Edit3:
Décidemmen, c'est compliqué!

If the current node is not then a ruby element, this is a parse error; pop all the nodes from the current node up to the node immediately before the bottommost ruby element on the stack of open elements.

On est dans ce cas, il y a donc une parse error et l'élément <rtc> devrait être entièrement supprimé du DOM.

Mais je ne suis plus sûr de rien...

[Zefling]

Ce que j'aime c'est HTML5 n'est pas en accord avec Ruby Annotation. Je vais me démerdé comment du coup ?

Edit2:
Quoique, si je lis ceci (la définition de "generate implied end tags"):

When the steps below require the UA to generate implied end tags, then, while the current node is a dd element, a dt element, an li element, an option element, an optgroup element, a p element, an rp element, or an rt element, the UA must pop the current node off the stack of open elements.

Il ne devrait pas fermer <rtc>. Cela pourrait bien être un bug dans le parser HTML5 de Firefox.

Il faudrait reporter le bug pour voir si c'est bien le cas ?

Édit : faut que j'arrête les tests, Firefox 4 qui me prend 3,9 Gio de RAM... (5,7 Gio en commit) j'avais jamais vu ça pour une application.

Édit 2 : j'ai essayé de forcer « Content-Type: application/xhtml+xml; charset=utf-8 » pour voir si la structure XML résoudrait le problème, mais ça me fait planter les pages au niveau du doctype <!DOCTYPE html> Je trouve pas d'infos, à croire que tout est fait pour ne pas utiliser XML en HTML5.

Édit 3 : J'ai trouvé, il faut juste ne pas mettre le tag XML, ma page passait à quelques détails près (les &nbsp; sont interdit). Bref, en XHTML5 j'ai exactement la même chose que XHTML 1.1 pour la structure de <ruby>, ça doit venir de la structure HTML et non XHTML.

[Zefling]

Voilà qui va faire plaisir à beaucoup de monde!

window.alert(), window.prompt() et window.confirm() seront modaux à l'onglet et non plus à la fenêtre, dès la prochaine nocturne.

Cela ne correspond pas encore à toutes les alertes (la fenêtre des mots de passe par exemple n'en fait pas partie), mais c'est un progrès significatif. Je pense pour ma part qu'il s'agit du problème d'UX le plus grave de Firefox (en fait surtout le problème des fenêtres de mots de passe): le voir s'en aller (même partiellement) est vraiment chouette.

Bug 59314 [Toolkit:General]-Alerts should be content-modal, not window-modal.

Ça floute tout le contenu de l'onget qui est donc bloqué (ascenseur compris).



C'est pas mal, maintenant il n'y a rien qui annonce qu'un onglet est bloqué.

[Xefir]

Voilà qui va faire plaisir à beaucoup de monde!

window.alert(), window.prompt() et window.confirm() seront modaux à l'onglet et non plus à la fenêtre, dès la prochaine nocturne.

Cela ne correspond pas encore à toutes les alertes (la fenêtre des mots de passe par exemple n'en fait pas partie), mais c'est un progrès significatif. Je pense pour ma part qu'il s'agit du problème d'UX le plus grave de Firefox (en fait surtout le problème des fenêtres de mots de passe): le voir s'en aller (même partiellement) est vraiment chouette.

Bug 59314 [Toolkit:General]-Alerts should be content-modal, not window-modal.

Ça floute tout le contenu de l'onget qui est donc bloqué (ascenseur compris).



C'est pas mal, maintenant il n'y a rien qui annonce qu'un onglet est bloqué.

C'est pas mal en effet, mais il reste encore les fenêtre d'erreur qui elle restent bloquantes.
Surtout celle-ci qui est très pénible :



Allez sur cette page, et vous comprendrez :
http://www.koreus.com/modules/news/

Autre chose assez bizarre, sur les animations flash, les zones transparentes se retrouve noire :s
Faites le test sur ce site par exemple : http://s2.noelshack.com/

Ces bugs sont-ils connus ?

Bonne soirée,
Xéfir Destiny

[Zefling]

Ouais, ça ne fonctionne pas pour toutes les box pour l'instant.

Il y a déjà pas mal de retour dans le tracker.

Par contre j'ai pas de problème sur mon site et le Flash reste transparent.