> En fait, il y a plusieurs raisons possibles pour conserver un tel
> texte. Si on envoie un message et que le serveur plante à ce moment
> ou encore ne peut pas le traiter comme il faut le texte (argument
> manquant ou non approprié par exemple).
Ça, c'est déjà le cas il me semble. Si on revient en arrière on doit
retrouver le contenu du champ, conservé en mémoire. Inutile en revanche
de le stocker sur disque.
nOn, pas pour un textarea justement :)
et cest justement pour ça que j'en ai (provisoirement) l'utilité:
ETAPE 1) je valide mon formulaire, mais comme mon code est tout pourri
ça marche pas
ETAPE 2) je retourne sur la page précédente, et là... éh non, je suis
obligé de tout retaper..
> En fait, il y a plusieurs raisons possibles pour conserver un tel
> texte. Si on envoie un message et que le serveur plante à ce moment
> ou encore ne peut pas le traiter comme il faut le texte (argument
> manquant ou non approprié par exemple).
Ça, c'est déjà le cas il me semble. Si on revient en arrière on doit
retrouver le contenu du champ, conservé en mémoire. Inutile en revanche
de le stocker sur disque.
nOn, pas pour un textarea justement :)
et cest justement pour ça que j'en ai (provisoirement) l'utilité:
ETAPE 1) je valide mon formulaire, mais comme mon code est tout pourri
ça marche pas
ETAPE 2) je retourne sur la page précédente, et là... éh non, je suis
obligé de tout retaper..
> En fait, il y a plusieurs raisons possibles pour conserver un tel
> texte. Si on envoie un message et que le serveur plante à ce moment
> ou encore ne peut pas le traiter comme il faut le texte (argument
> manquant ou non approprié par exemple).
Ça, c'est déjà le cas il me semble. Si on revient en arrière on doit
retrouver le contenu du champ, conservé en mémoire. Inutile en revanche
de le stocker sur disque.
nOn, pas pour un textarea justement :)
et cest justement pour ça que j'en ai (provisoirement) l'utilité:
ETAPE 1) je valide mon formulaire, mais comme mon code est tout pourri
ça marche pas
ETAPE 2) je retourne sur la page précédente, et là... éh non, je suis
obligé de tout retaper..
Le 06/07/2009 18:25, samuel a écrit :
>> > En fait, il y a plusieurs raisons possibles pour conserver un tel
>> > texte. Si on envoie un message et que le serveur plante à ce mo ment
>> > ou encore ne peut pas le traiter comme il faut le texte (argument
>> > manquant ou non approprié par exemple).
>> Ça, c'est déjà le cas il me semble. Si on revient en arrière o n doit
>> retrouver le contenu du champ, conservé en mémoire. Inutile en rev anche
>> de le stocker sur disque.
> nOn, pas pour un textarea justement :)
> et cest justement pour ça que j'en ai (provisoirement) l'utilité:
> ETAPE 1) je valide mon formulaire, mais comme mon code est tout pourri
> ça marche pas
> ETAPE 2) je retourne sur la page précédente, et là... éh non, j e suis
> obligé de tout retaper..
Ok. Eh bien alors c'est ça qu'il faudrait faire corriger, plutôt que de
demander de sauvegarder les textarea comme des mots de passe.
Au passage, je ne sais pas si tu es allé faire un tour dans les mots de
passe stockés (dans le cas de seamonkey, c'est Outils > Gestionnaire de s
mots de passe > Voir les mots de passe stockés). On peut y voir qu'à
chaque ligne on trouve trois infos : l'url, le login et le mot de passe
(caché par défaut), les deux premiers servant d'index. Dans le cas d' un
formulaire avec trois champs d'input ou plus, que prendrais-tu comme
index et comment stockerais-tu les valeurs ?
Le 06/07/2009 18:25, samuel a écrit :
>> > En fait, il y a plusieurs raisons possibles pour conserver un tel
>> > texte. Si on envoie un message et que le serveur plante à ce mo ment
>> > ou encore ne peut pas le traiter comme il faut le texte (argument
>> > manquant ou non approprié par exemple).
>> Ça, c'est déjà le cas il me semble. Si on revient en arrière o n doit
>> retrouver le contenu du champ, conservé en mémoire. Inutile en rev anche
>> de le stocker sur disque.
> nOn, pas pour un textarea justement :)
> et cest justement pour ça que j'en ai (provisoirement) l'utilité:
> ETAPE 1) je valide mon formulaire, mais comme mon code est tout pourri
> ça marche pas
> ETAPE 2) je retourne sur la page précédente, et là... éh non, j e suis
> obligé de tout retaper..
Ok. Eh bien alors c'est ça qu'il faudrait faire corriger, plutôt que de
demander de sauvegarder les textarea comme des mots de passe.
Au passage, je ne sais pas si tu es allé faire un tour dans les mots de
passe stockés (dans le cas de seamonkey, c'est Outils > Gestionnaire de s
mots de passe > Voir les mots de passe stockés). On peut y voir qu'à
chaque ligne on trouve trois infos : l'url, le login et le mot de passe
(caché par défaut), les deux premiers servant d'index. Dans le cas d' un
formulaire avec trois champs d'input ou plus, que prendrais-tu comme
index et comment stockerais-tu les valeurs ?
Le 06/07/2009 18:25, samuel a écrit :
>> > En fait, il y a plusieurs raisons possibles pour conserver un tel
>> > texte. Si on envoie un message et que le serveur plante à ce mo ment
>> > ou encore ne peut pas le traiter comme il faut le texte (argument
>> > manquant ou non approprié par exemple).
>> Ça, c'est déjà le cas il me semble. Si on revient en arrière o n doit
>> retrouver le contenu du champ, conservé en mémoire. Inutile en rev anche
>> de le stocker sur disque.
> nOn, pas pour un textarea justement :)
> et cest justement pour ça que j'en ai (provisoirement) l'utilité:
> ETAPE 1) je valide mon formulaire, mais comme mon code est tout pourri
> ça marche pas
> ETAPE 2) je retourne sur la page précédente, et là... éh non, j e suis
> obligé de tout retaper..
Ok. Eh bien alors c'est ça qu'il faudrait faire corriger, plutôt que de
demander de sauvegarder les textarea comme des mots de passe.
Au passage, je ne sais pas si tu es allé faire un tour dans les mots de
passe stockés (dans le cas de seamonkey, c'est Outils > Gestionnaire de s
mots de passe > Voir les mots de passe stockés). On peut y voir qu'à
chaque ligne on trouve trois infos : l'url, le login et le mot de passe
(caché par défaut), les deux premiers servant d'index. Dans le cas d' un
formulaire avec trois champs d'input ou plus, que prendrais-tu comme
index et comment stockerais-tu les valeurs ?
>> Ça, c'est déjà le cas il me semble. Si on revient en arrière on doit
>> retrouver le contenu du champ, conservé en mémoire. Inutile en revanche
>> de le stocker sur disque.
> nOn, pas pour un textarea justement :)
Ok. Eh bien alors c'est ça qu'il faudrait faire corriger, plutôt que de
demander de sauvegarder les textarea comme des mots de passe.
cest facile comme réponse, non? :)
Au passage, je ne sais pas si tu es allé faire un tour dans les mots de
passe stockés (dans le cas de seamonkey, c'est Outils > Gestionnaire des
mots de passe > Voir les mots de passe stockés). On peut y voir qu'à
chaque ligne on trouve trois infos : l'url, le login et le mot de passe
(caché par défaut), les deux premiers servant d'index. Dans le cas d'un
formulaire avec trois champs d'input ou plus, que prendrais-tu comme
index et comment stockerais-tu les valeurs ?
à mon avis c'est l'attribut name..
d'ailleurs qd tu remplis un formulaire souvent t'as pas besoin de
retaper ton nom, prénom, n°tel, ni adresse mail, t'as juste à choisir
ce qui va bien :)
et du coup si ya un input qui sappelle preference_sexuelle, tu risque
pas d'y retrouver la réponse à ta question secrète pour retrouver ton
mot de passe, à savoir le nom de jeune fille de ta maman, ou celui de
ton animal de compagnie.
je pense que c'est ça, mais après cest une hypothèse.
>> Ça, c'est déjà le cas il me semble. Si on revient en arrière on doit
>> retrouver le contenu du champ, conservé en mémoire. Inutile en revanche
>> de le stocker sur disque.
> nOn, pas pour un textarea justement :)
Ok. Eh bien alors c'est ça qu'il faudrait faire corriger, plutôt que de
demander de sauvegarder les textarea comme des mots de passe.
cest facile comme réponse, non? :)
Au passage, je ne sais pas si tu es allé faire un tour dans les mots de
passe stockés (dans le cas de seamonkey, c'est Outils > Gestionnaire des
mots de passe > Voir les mots de passe stockés). On peut y voir qu'à
chaque ligne on trouve trois infos : l'url, le login et le mot de passe
(caché par défaut), les deux premiers servant d'index. Dans le cas d'un
formulaire avec trois champs d'input ou plus, que prendrais-tu comme
index et comment stockerais-tu les valeurs ?
à mon avis c'est l'attribut name..
d'ailleurs qd tu remplis un formulaire souvent t'as pas besoin de
retaper ton nom, prénom, n°tel, ni adresse mail, t'as juste à choisir
ce qui va bien :)
et du coup si ya un input qui sappelle preference_sexuelle, tu risque
pas d'y retrouver la réponse à ta question secrète pour retrouver ton
mot de passe, à savoir le nom de jeune fille de ta maman, ou celui de
ton animal de compagnie.
je pense que c'est ça, mais après cest une hypothèse.
>> Ça, c'est déjà le cas il me semble. Si on revient en arrière on doit
>> retrouver le contenu du champ, conservé en mémoire. Inutile en revanche
>> de le stocker sur disque.
> nOn, pas pour un textarea justement :)
Ok. Eh bien alors c'est ça qu'il faudrait faire corriger, plutôt que de
demander de sauvegarder les textarea comme des mots de passe.
cest facile comme réponse, non? :)
Au passage, je ne sais pas si tu es allé faire un tour dans les mots de
passe stockés (dans le cas de seamonkey, c'est Outils > Gestionnaire des
mots de passe > Voir les mots de passe stockés). On peut y voir qu'à
chaque ligne on trouve trois infos : l'url, le login et le mot de passe
(caché par défaut), les deux premiers servant d'index. Dans le cas d'un
formulaire avec trois champs d'input ou plus, que prendrais-tu comme
index et comment stockerais-tu les valeurs ?
à mon avis c'est l'attribut name..
d'ailleurs qd tu remplis un formulaire souvent t'as pas besoin de
retaper ton nom, prénom, n°tel, ni adresse mail, t'as juste à choisir
ce qui va bien :)
et du coup si ya un input qui sappelle preference_sexuelle, tu risque
pas d'y retrouver la réponse à ta question secrète pour retrouver ton
mot de passe, à savoir le nom de jeune fille de ta maman, ou celui de
ton animal de compagnie.
je pense que c'est ça, mais après cest une hypothèse.
Le 06/07/2009 20:04, samuel a écrit :Ça, c'est déjà le cas il me semble. Si on revient en arrière on doit
retrouver le contenu du champ, conservé en mémoire. Inutile en revanche
de le stocker sur disque.
nOn, pas pour un textarea justement :)
Ok. Eh bien alors c'est ça qu'il faudrait faire corriger, plutôt que de
demander de sauvegarder les textarea comme des mots de passe.
cest facile comme réponse, non? :)
Je ne sais pas ce que tu appelles « facile », concernant une réponse
faite par quelqu'un qui voit ça de l'extérieur et qui n'est absolument
pas capable de corriger des comportements de Firefox.Au passage, je ne sais pas si tu es allé faire un tour dans les mots de
passe stockés (dans le cas de seamonkey, c'est Outils > Gestionnaire des
mots de passe > Voir les mots de passe stockés). On peut y voir qu'à
chaque ligne on trouve trois infos : l'url, le login et le mot de passe
(caché par défaut), les deux premiers servant d'index. Dans le cas d'un
formulaire avec trois champs d'input ou plus, que prendrais-tu comme
index et comment stockerais-tu les valeurs ?
à mon avis c'est l'attribut name..
Hein ? Quel attribut name ? Et pourquoi un attribut name ?
Je crois qu'on ne s'est encore une fois pas compris. Lorsque sur une
page URL1 il y a deux champs input, un INPUT1 de type text et un INPUT2
de type password, les navigateurs que je connais associent à la paire
(URL1, valeur de INPUT1) le mot de passe (valeur de INPUT2). Si tu
reviens pour la première fois sur URL1, cela préremplit INPUT1 et
INPUT2. Si alors tu choisis une autre valeur pour INPUT1 (et en général
pour INPUT2 aussi), le navigateur crée une nouvelle association, et au
coup suivant il te propose la liste des « INPUT1 » avant de préremplir
à la foiS INPUT1 et INPUT2. Si au contraire tu choisis l'un des INPUT1
déjà stockés mais que tu changes INPUT2, au lieu de créer une nouvelle
association cela écrase celle qui existait déjà. Etc.
Il y a donc trois rôles très différents joués par ces trois éléments
différents que sont 1:l'url, 2:l'input de type texte et 3:l'input de
type password. Ce que je te demande, puisque tu veux étendre cela pour
accepter des textarea, c'est à quel endroit tu les insères dans ce
schéma rigide. Pour moi, ce n'est pas possible ; tu peux bien inventer
quelque chose de totalement nouveau, mais pas prétendre réutiliser le
mécanisme existant.
Le 06/07/2009 20:04, samuel a écrit :
Ça, c'est déjà le cas il me semble. Si on revient en arrière on doit
retrouver le contenu du champ, conservé en mémoire. Inutile en revanche
de le stocker sur disque.
nOn, pas pour un textarea justement :)
Ok. Eh bien alors c'est ça qu'il faudrait faire corriger, plutôt que de
demander de sauvegarder les textarea comme des mots de passe.
cest facile comme réponse, non? :)
Je ne sais pas ce que tu appelles « facile », concernant une réponse
faite par quelqu'un qui voit ça de l'extérieur et qui n'est absolument
pas capable de corriger des comportements de Firefox.
Au passage, je ne sais pas si tu es allé faire un tour dans les mots de
passe stockés (dans le cas de seamonkey, c'est Outils > Gestionnaire des
mots de passe > Voir les mots de passe stockés). On peut y voir qu'à
chaque ligne on trouve trois infos : l'url, le login et le mot de passe
(caché par défaut), les deux premiers servant d'index. Dans le cas d'un
formulaire avec trois champs d'input ou plus, que prendrais-tu comme
index et comment stockerais-tu les valeurs ?
à mon avis c'est l'attribut name..
Hein ? Quel attribut name ? Et pourquoi un attribut name ?
Je crois qu'on ne s'est encore une fois pas compris. Lorsque sur une
page URL1 il y a deux champs input, un INPUT1 de type text et un INPUT2
de type password, les navigateurs que je connais associent à la paire
(URL1, valeur de INPUT1) le mot de passe (valeur de INPUT2). Si tu
reviens pour la première fois sur URL1, cela préremplit INPUT1 et
INPUT2. Si alors tu choisis une autre valeur pour INPUT1 (et en général
pour INPUT2 aussi), le navigateur crée une nouvelle association, et au
coup suivant il te propose la liste des « INPUT1 » avant de préremplir
à la foiS INPUT1 et INPUT2. Si au contraire tu choisis l'un des INPUT1
déjà stockés mais que tu changes INPUT2, au lieu de créer une nouvelle
association cela écrase celle qui existait déjà. Etc.
Il y a donc trois rôles très différents joués par ces trois éléments
différents que sont 1:l'url, 2:l'input de type texte et 3:l'input de
type password. Ce que je te demande, puisque tu veux étendre cela pour
accepter des textarea, c'est à quel endroit tu les insères dans ce
schéma rigide. Pour moi, ce n'est pas possible ; tu peux bien inventer
quelque chose de totalement nouveau, mais pas prétendre réutiliser le
mécanisme existant.
Le 06/07/2009 20:04, samuel a écrit :Ça, c'est déjà le cas il me semble. Si on revient en arrière on doit
retrouver le contenu du champ, conservé en mémoire. Inutile en revanche
de le stocker sur disque.
nOn, pas pour un textarea justement :)
Ok. Eh bien alors c'est ça qu'il faudrait faire corriger, plutôt que de
demander de sauvegarder les textarea comme des mots de passe.
cest facile comme réponse, non? :)
Je ne sais pas ce que tu appelles « facile », concernant une réponse
faite par quelqu'un qui voit ça de l'extérieur et qui n'est absolument
pas capable de corriger des comportements de Firefox.Au passage, je ne sais pas si tu es allé faire un tour dans les mots de
passe stockés (dans le cas de seamonkey, c'est Outils > Gestionnaire des
mots de passe > Voir les mots de passe stockés). On peut y voir qu'à
chaque ligne on trouve trois infos : l'url, le login et le mot de passe
(caché par défaut), les deux premiers servant d'index. Dans le cas d'un
formulaire avec trois champs d'input ou plus, que prendrais-tu comme
index et comment stockerais-tu les valeurs ?
à mon avis c'est l'attribut name..
Hein ? Quel attribut name ? Et pourquoi un attribut name ?
Je crois qu'on ne s'est encore une fois pas compris. Lorsque sur une
page URL1 il y a deux champs input, un INPUT1 de type text et un INPUT2
de type password, les navigateurs que je connais associent à la paire
(URL1, valeur de INPUT1) le mot de passe (valeur de INPUT2). Si tu
reviens pour la première fois sur URL1, cela préremplit INPUT1 et
INPUT2. Si alors tu choisis une autre valeur pour INPUT1 (et en général
pour INPUT2 aussi), le navigateur crée une nouvelle association, et au
coup suivant il te propose la liste des « INPUT1 » avant de préremplir
à la foiS INPUT1 et INPUT2. Si au contraire tu choisis l'un des INPUT1
déjà stockés mais que tu changes INPUT2, au lieu de créer une nouvelle
association cela écrase celle qui existait déjà. Etc.
Il y a donc trois rôles très différents joués par ces trois éléments
différents que sont 1:l'url, 2:l'input de type texte et 3:l'input de
type password. Ce que je te demande, puisque tu veux étendre cela pour
accepter des textarea, c'est à quel endroit tu les insères dans ce
schéma rigide. Pour moi, ce n'est pas possible ; tu peux bien inventer
quelque chose de totalement nouveau, mais pas prétendre réutiliser le
mécanisme existant.
Sauf qu'il y a aussi dans les navigateurs modernes une autre fonction
qui se souvient des entrées (indépendamment des password ou autres) et
te propose une série de possibilités en fonction des premières lettres
tapées. Ce qui est très pratique pour les entrées courtes et hautement
répétitives comme les adresses mail, les prénoms ou autre, mais
inutilisables pour des champs textarea, comme tout connaisseur des
bulles pontificales vous dira. :-)
Sauf qu'il y a aussi dans les navigateurs modernes une autre fonction
qui se souvient des entrées (indépendamment des password ou autres) et
te propose une série de possibilités en fonction des premières lettres
tapées. Ce qui est très pratique pour les entrées courtes et hautement
répétitives comme les adresses mail, les prénoms ou autre, mais
inutilisables pour des champs textarea, comme tout connaisseur des
bulles pontificales vous dira. :-)
Sauf qu'il y a aussi dans les navigateurs modernes une autre fonction
qui se souvient des entrées (indépendamment des password ou autres) et
te propose une série de possibilités en fonction des premières lettres
tapées. Ce qui est très pratique pour les entrées courtes et hautement
répétitives comme les adresses mail, les prénoms ou autre, mais
inutilisables pour des champs textarea, comme tout connaisseur des
bulles pontificales vous dira. :-)
Sauf qu'il y a aussi dans les navigateurs modernes une autre fonction
qui se souvient des entrées (indépendamment des password ou autres) et
te propose une série de possibilités en fonction des premières lettres
tapées. Ce qui est très pratique pour les entrées courtes et hautement
répétitives comme les adresses mail, les prénoms ou autre, mais
inutilisables pour des champs textarea, comme tout connaisseur des
bulles pontificales vous dira. :-)
Sauf qu'il y a aussi dans les navigateurs modernes une autre fonction
qui se souvient des entrées (indépendamment des password ou autres) et
te propose une série de possibilités en fonction des premières lettres
tapées. Ce qui est très pratique pour les entrées courtes et hautement
répétitives comme les adresses mail, les prénoms ou autre, mais
inutilisables pour des champs textarea, comme tout connaisseur des
bulles pontificales vous dira. :-)
Sauf qu'il y a aussi dans les navigateurs modernes une autre fonction
qui se souvient des entrées (indépendamment des password ou autres) et
te propose une série de possibilités en fonction des premières lettres
tapées. Ce qui est très pratique pour les entrées courtes et hautement
répétitives comme les adresses mail, les prénoms ou autre, mais
inutilisables pour des champs textarea, comme tout connaisseur des
bulles pontificales vous dira. :-)
Ah, je n'avais donc effectivement pas compris la question, y compris
après l'intervention de gab qui m'a aiguillé vers un autre mécanisme
que celui auquel pensait samuel. Désolé, je ne savais pas que cela
existait, car je n'ai pas ça dans Seamonkey (ou alors ça existe mais
c'est désactivé par défaut).
Ah, je n'avais donc effectivement pas compris la question, y compris
après l'intervention de gab qui m'a aiguillé vers un autre mécanisme
que celui auquel pensait samuel. Désolé, je ne savais pas que cela
existait, car je n'ai pas ça dans Seamonkey (ou alors ça existe mais
c'est désactivé par défaut).
Ah, je n'avais donc effectivement pas compris la question, y compris
après l'intervention de gab qui m'a aiguillé vers un autre mécanisme
que celui auquel pensait samuel. Désolé, je ne savais pas que cela
existait, car je n'ai pas ça dans Seamonkey (ou alors ça existe mais
c'est désactivé par défaut).
Ah, je n'avais donc effectivement pas compris la question, y compris
après l'intervention de gab qui m'a aiguillé vers un autre mécanisme
que celui auquel pensait samuel. Désolé, je ne savais pas que cela
existait, car je n'ai pas ça dans Seamonkey (ou alors ça existe mais
c'est désactivé par défaut).
on n'allait pas insister car manifestement, tu n'avais pas le logiciel
sous le nez
mais avec google ou une autre page Web, il se rappelle de
tes précédentes entrées (sans que cela soit un user/password)
Ah, je n'avais donc effectivement pas compris la question, y compris
après l'intervention de gab qui m'a aiguillé vers un autre mécanisme
que celui auquel pensait samuel. Désolé, je ne savais pas que cela
existait, car je n'ai pas ça dans Seamonkey (ou alors ça existe mais
c'est désactivé par défaut).
on n'allait pas insister car manifestement, tu n'avais pas le logiciel
sous le nez
mais avec google ou une autre page Web, il se rappelle de
tes précédentes entrées (sans que cela soit un user/password)
Ah, je n'avais donc effectivement pas compris la question, y compris
après l'intervention de gab qui m'a aiguillé vers un autre mécanisme
que celui auquel pensait samuel. Désolé, je ne savais pas que cela
existait, car je n'ai pas ça dans Seamonkey (ou alors ça existe mais
c'est désactivé par défaut).
on n'allait pas insister car manifestement, tu n'avais pas le logiciel
sous le nez
mais avec google ou une autre page Web, il se rappelle de
tes précédentes entrées (sans que cela soit un user/password)
Le 07/07/2009 09:14, gab m'a répondu :
>> Ah, je n'avais donc effectivement pas compris la question, y compris
>> après l'intervention de gab qui m'a aiguillé vers un autre mécan isme
>> que celui auquel pensait samuel. Désolé, je ne savais pas que cela
>> existait, car je n'ai pas ça dans Seamonkey (ou alors ça existe ma is
>> c'est désactivé par défaut).
> on n'allait pas insister car manifestement, tu n'avais pas le logiciel
> sous le nez
Ç'aurait été sympa de ne pas me laisser m'enferrer dans le mécani sme
ident+password si tu avais compris que ce n'était pas ça ! ;-)
> mais avec google ou une autre page Web, il se rappelle de
> tes précédentes entrées (sans que cela soit un user/password)
Ben non, en tout cas pas mon SeaMonkey.
Qui plus est, dans Google il y a un mécanisme à base de JavaScript et
d'XmlHttpRequest (Ajax) qui fait des propositions, non pas selon ce que
tu as déjà saisi, mais selon les recherches les plus fréquentes des
autres utilisateurs. Strictement rien à voir avec un cache dans le
navigateur, donc.
(Quand à la mention des bulles pontificales c'est par ce qu'elles sont
indexées par leurs deux ou trois premiers mots, et que donc il y a de
nombreux quasi doublons...
Le 07/07/2009 09:14, gab m'a répondu :
>> Ah, je n'avais donc effectivement pas compris la question, y compris
>> après l'intervention de gab qui m'a aiguillé vers un autre mécan isme
>> que celui auquel pensait samuel. Désolé, je ne savais pas que cela
>> existait, car je n'ai pas ça dans Seamonkey (ou alors ça existe ma is
>> c'est désactivé par défaut).
> on n'allait pas insister car manifestement, tu n'avais pas le logiciel
> sous le nez
Ç'aurait été sympa de ne pas me laisser m'enferrer dans le mécani sme
ident+password si tu avais compris que ce n'était pas ça ! ;-)
> mais avec google ou une autre page Web, il se rappelle de
> tes précédentes entrées (sans que cela soit un user/password)
Ben non, en tout cas pas mon SeaMonkey.
Qui plus est, dans Google il y a un mécanisme à base de JavaScript et
d'XmlHttpRequest (Ajax) qui fait des propositions, non pas selon ce que
tu as déjà saisi, mais selon les recherches les plus fréquentes des
autres utilisateurs. Strictement rien à voir avec un cache dans le
navigateur, donc.
(Quand à la mention des bulles pontificales c'est par ce qu'elles sont
indexées par leurs deux ou trois premiers mots, et que donc il y a de
nombreux quasi doublons...
Le 07/07/2009 09:14, gab m'a répondu :
>> Ah, je n'avais donc effectivement pas compris la question, y compris
>> après l'intervention de gab qui m'a aiguillé vers un autre mécan isme
>> que celui auquel pensait samuel. Désolé, je ne savais pas que cela
>> existait, car je n'ai pas ça dans Seamonkey (ou alors ça existe ma is
>> c'est désactivé par défaut).
> on n'allait pas insister car manifestement, tu n'avais pas le logiciel
> sous le nez
Ç'aurait été sympa de ne pas me laisser m'enferrer dans le mécani sme
ident+password si tu avais compris que ce n'était pas ça ! ;-)
> mais avec google ou une autre page Web, il se rappelle de
> tes précédentes entrées (sans que cela soit un user/password)
Ben non, en tout cas pas mon SeaMonkey.
Qui plus est, dans Google il y a un mécanisme à base de JavaScript et
d'XmlHttpRequest (Ajax) qui fait des propositions, non pas selon ce que
tu as déjà saisi, mais selon les recherches les plus fréquentes des
autres utilisateurs. Strictement rien à voir avec un cache dans le
navigateur, donc.
(Quand à la mention des bulles pontificales c'est par ce qu'elles sont
indexées par leurs deux ou trois premiers mots, et que donc il y a de
nombreux quasi doublons...
(Quand à la mention des bulles pontificales c'est par ce qu'elles sont
indexées par leurs deux ou trois premiers mots, et que donc il y a de
nombreux quasi doublons...
ah! intéressant!
t'as bossé sur les pc du vatican? :)
(Quand à la mention des bulles pontificales c'est par ce qu'elles sont
indexées par leurs deux ou trois premiers mots, et que donc il y a de
nombreux quasi doublons...
ah! intéressant!
t'as bossé sur les pc du vatican? :)
(Quand à la mention des bulles pontificales c'est par ce qu'elles sont
indexées par leurs deux ou trois premiers mots, et que donc il y a de
nombreux quasi doublons...
ah! intéressant!
t'as bossé sur les pc du vatican? :)