Closed Bug 113779 Opened 23 years ago Closed 21 years ago

The site displays badly (lots of blank space) and scroll bar acts strangely (?)

Categories

(Core :: Layout: Text and Fonts, defect)

x86
Windows NT
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: wstinson, Assigned: rbs)

References

()

Details

(Keywords: fixed1.4.1, intl, top100)

Attachments

(9 files, 2 obsolete files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112009

The URL www.yahoo.fr redirects to http://fr.yahoo.com/

This page displays but there is a huge blank space (many pages long) between the
top and bottom parts of the URL. The scroll bar appears to behave 'strangely'
probably because the blanks space is so large. The only way to scroll down is to
drag the scrolling box down in the scroll bar (or I suppose wait a very long
time to scroll down normally)

Reproducible: Always
Steps to Reproduce:
1. Open URL www.yahoo.fr
2. this automatically redirects to http://fr.yahoo.com/
3. The problem is visible (only the top part of the page is shown - then a big
blank part)

Actual Results:  First part of the page, a  huge blank section, then the rest of
the page

Expected Results:  Page displayed normally (no blank area). This page shows fine
on IE.

The problem seems to triggered somewhere in the following piece of HTML some
where after "Version 6 special Yahoo" and before "Yahoo Voyages"
<b><a
href=http://fr.rd.yahoo.com/M=200025416.200583769.202204094.200054770/D=fr/S=15432978:NE/A=200292397/R=0/*http://fr.ie.yahoo.com/>Microsoft
Internet Explorer Version 6
Sp&eacute;cial Yahoo!</a></b> </td></tr></table><table border=0 cellspacing=0
cellpadding=3 width=640>
<tr><td align=center>
<input size=30 name=p> <input type=submit value=Recherche>&nbsp;<small><a
href=bb>Recherche avancée</a></small>


</td></tr><tr><td></td></tr><tr><td align=center nowrap>
<b><a href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/><img
src=http://eur.i1.yimg.com/eur.yimg.com/i/fr/tr/16tr.gif width=16 height=16
alt=Voyages border=0></a>&nbsp;<a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/>Yahoo!
Voyages</a>&nbsp;: <a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/loc/>Offres
sports d&#146;hiver</a>&nbsp;<a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/loc/><img
src=http://eur.i1.yimg.com/eur.yimg.com/i/fr/tr/ski16.gif width=16 height=16
alt=Ski border=0></a> &middot; <a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/flights/>Billets
d&#146;avion</a>&nbsp;<a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/flights/><img
src=http://eur.i1.yimg.com/eur.yimg.com/i/fr/tr/pln.gif width=16 height=16
alt=Vols border=0></a> &middot; <a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/affaires/>Bonnes
affaires</a>&nbsp;<a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/affaires/><img
src=http://eur.i1.yimg.com/eur.yimg.com/i/fr/tr/seu.gif width=16 height=16
alt=BonnesAffaires border=0></a> ...</b> </td></tr>
<tr><td align=center nowrap><small>
<b>Infos&nbsp;:</b> <a href=bc>Actualit&eacute;s</a> &#183; <a
href=bf><b>Finance</b></a> &#183; <a href=jd>Sport</a> &#183; <a
href=ja>M&eacute;t&eacute;o</a> &#183; <a href=ma>Cartes</a> &nbsp;
<b>Loisirs&nbsp;:</b> <a href=jx><b>Jeux</b></a> &#183; <a
HREF=bh>Logith&egrave;que</a> &#183; <a HREF=mu>Musique</a> &#183; <a
HREF=ep>Encyclop&eacute;die</a> &#183; <a href=bg><b>Astrologie</b></a> &#183;
<a href=au>Auto</a><br><b>Communication&nbsp;:</b> <a href=be>Courrier</a>
&#183; <a href=ab>Carnet d&#146;adresses</a> &#183; <a href=cv>Cartes de
voeux</a> &#183; <a href=bj>Messenger</a> &#183; <a href=gr><b>Groupes</b></a>
&#183; <a href=tc>Tchatche</a> &#183; <a href=yp>Annuaire Pro</a> &#183; <a
href=mo>Mobile</a><br><b>Achats&nbsp;:</b> <a href=bk>Shopping</a> &#183; <a
href=tx><b>Voyages</b></a> &#183; <a href=en>Ench&egrave;res</a> &#183; <a
href=jc>Annonces</a> &nbsp; <b>Perso&nbsp;:</b> <a href=bi><b>Mon Yahoo!</b></a>
&#183; <a href=cp>Compagnon</a> &#183; <a href=ag>Agenda</a> &#183; <a
href=ph>Photos</a> &nbsp;--&nbsp; <b><i><a href=jh>et aussi...</a></i></b> 




Browser is Mozilla 0.9.6

Cut/Paste of the ful page source (for future reference):
*************************************************************
<html>
<head><title>Yahoo! France</title><base href=http://fr.yahoo.com/r/>

<!-- meta http-equiv="PICS-Label" content='(PICS-1.1
"http://www.rsac.org/ratingsv01.html" l gen true for "http://fr.yahoo.com" r (n
0 s 0 v 0 l 0))' --></head>


<body onLoad="document.f.p.focus();">
<center><form
action="http://fr.rd.yahoo.com/hps/*http://fr.search.yahoo.com/search/fr" name=f>
<map name=m><area coords=0,0,52,52 href=bf alt=Finance><area coords=53,0,121,52
href=tc alt=Tchatche><area coords=122,0,191,52 href=be alt=Courrier><area
coords=441,0,510,52 href=jb alt=Nouveautés><area coords=511,0,579,52 href=bi
alt="Mon Yahoo!"><area coords=580,0,637,52 href=hf alt=Aide></map><img width=638
height=60 border=0 usemap=#m
src=http://eur.i1.yimg.com/eur.yimg.com/i/fr/g/m5.gif alt="Yahoo! France"><br>


<table border=0 cellspacing=0 cellpadding=3 width=640>
<tr><td align=center width=204>
<b><a href=http://fr.yahoo.com/home/mobile/*http://fr.mobile.yahoo.com/>Yahoo!
Mobile</a><br><small><a
href=http://fr.yahoo.com/home/mobile/*http://fr.mobile.yahoo.com/ringlogo.html>Changez
vos logos et sonneries&nbsp;!</a></small></b></td><td align=center width=230>

<a
href="http://fr.rd.yahoo.com/M=200025416.200535978.202168061.200000444/D=fr/S=15432978:N/A=200295297/?http://fifaworldcup.yahoo.com/fr"
target="_top"><img width=230 height=33
src="http://eur.a1.yimg.com/eur.yimg.com/a/fr/autopromo/fifafrntraf.gif" alt=""
border=0></a>
</td><td align=center width=203>

<b><a
href=http://fr.rd.yahoo.com/M=200025416.200583769.202204094.200054770/D=fr/S=15432978:NE/A=200292397/R=0/*http://fr.ie.yahoo.com/>Microsoft
Internet Explorer Version 6
Sp&eacute;cial Yahoo!</a></b> </td></tr></table><table border=0 cellspacing=0
cellpadding=3 width=640>
<tr><td align=center>
<input size=30 name=p> <input type=submit value=Recherche>&nbsp;<small><a
href=bb>Recherche avancée</a></small>


</td></tr><tr><td></td></tr><tr><td align=center nowrap>
<b><a href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/><img
src=http://eur.i1.yimg.com/eur.yimg.com/i/fr/tr/16tr.gif width=16 height=16
alt=Voyages border=0></a>&nbsp;<a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/>Yahoo!
Voyages</a>&nbsp;: <a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/loc/>Offres
sports d&#146;hiver</a>&nbsp;<a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/loc/><img
src=http://eur.i1.yimg.com/eur.yimg.com/i/fr/tr/ski16.gif width=16 height=16
alt=Ski border=0></a> &middot; <a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/flights/>Billets
d&#146;avion</a>&nbsp;<a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/flights/><img
src=http://eur.i1.yimg.com/eur.yimg.com/i/fr/tr/pln.gif width=16 height=16
alt=Vols border=0></a> &middot; <a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/affaires/>Bonnes
affaires</a>&nbsp;<a
href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/affaires/><img
src=http://eur.i1.yimg.com/eur.yimg.com/i/fr/tr/seu.gif width=16 height=16
alt=BonnesAffaires border=0></a> ...</b> </td></tr>
<tr><td align=center nowrap><small>
<b>Infos&nbsp;:</b> <a href=bc>Actualit&eacute;s</a> &#183; <a
href=bf><b>Finance</b></a> &#183; <a href=jd>Sport</a> &#183; <a
href=ja>M&eacute;t&eacute;o</a> &#183; <a href=ma>Cartes</a> &nbsp;
<b>Loisirs&nbsp;:</b> <a href=jx><b>Jeux</b></a> &#183; <a
HREF=bh>Logith&egrave;que</a> &#183; <a HREF=mu>Musique</a> &#183; <a
HREF=ep>Encyclop&eacute;die</a> &#183; <a href=bg><b>Astrologie</b></a> &#183;
<a href=au>Auto</a><br><b>Communication&nbsp;:</b> <a href=be>Courrier</a>
&#183; <a href=ab>Carnet d&#146;adresses</a> &#183; <a href=cv>Cartes de
voeux</a> &#183; <a href=bj>Messenger</a> &#183; <a href=gr><b>Groupes</b></a>
&#183; <a href=tc>Tchatche</a> &#183; <a href=yp>Annuaire Pro</a> &#183; <a
href=mo>Mobile</a><br><b>Achats&nbsp;:</b> <a href=bk>Shopping</a> &#183; <a
href=tx><b>Voyages</b></a> &#183; <a href=en>Ench&egrave;res</a> &#183; <a
href=jc>Annonces</a> &nbsp; <b>Perso&nbsp;:</b> <a href=bi><b>Mon Yahoo!</b></a>
&#183; <a href=cp>Compagnon</a> &#183; <a href=ag>Agenda</a> &#183; <a
href=ph>Photos</a> &nbsp;--&nbsp; <b><i><a href=jh>et aussi...</a></i></b>
</small></td></tr></table><table border=0 cellspacing=7 cellpadding=2><tr><td
valign=top align=center>
<table border=0 width="100%" cellspacing=0><tr><td align=center
bgcolor=#3366cc><table border=0 width="100%" cellspacing=0><tr><td align=center
bgcolor=#ffffff>
<table border=0 width="100%" cellspacing=0 cellpadding=0><tr><td align=center
colspan=5><a href=http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/><img
src=http://eur.i1.yimg.com/eur.yimg.com/i//fr/fi/i/fi.gif width=16 height=16
border=0 alt=Finance></a><font face=arial>&nbsp;&nbsp;<a
href=http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/><b>Yahoo!
Finance</b></a> <small>- Suivez toute l'actualité
financière&nbsp;!</small></font></td></tr>
<tr><td>&nbsp;</td><td>&nbsp;<small><b>Cotations</b><br>
&nbsp;·&nbsp;<a
href="http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/q?s=@350000.PA&f=snlcvi">CAC
40</a><br>
&nbsp;·&nbsp;<a
href="http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/q?s=@SRD_AB.PA&f=snlcvi">SRD</a><br>
&nbsp;·&nbsp;<a
href="http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/q?s=^DJI&d=c&k=c4&t=1d"><b>Dow
Jones</b></a> / <a
href="http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/q?s=^IXIC&d=c&k=c4&t=1d">Nasdaq</a><br>
&nbsp;·&nbsp;<a
href="http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/a43?u">Palmarès</a></small></td>
<td>&nbsp;&nbsp;&nbsp;</td><td>&nbsp;<small><b>Actualités/Analyses</b><br>
&nbsp;·&nbsp;<a
href="http://fr.yahoo.com/home/bf/*http://fr.biz.yahoo.com/paris.html">Séance du
jour</a><br>
&nbsp;·&nbsp;<a
href="http://fr.yahoo.com/home/bf/*http://fr.biz.yahoo.com/actualite/analyse/">Recommandations</a><br>
&nbsp;·&nbsp;<a
href="http://fr.yahoo.com/home/bf/*http://fr.biz.yahoo.com/screen/">Indices
sectoriels</a><br>
&nbsp;·&nbsp;<a
href="http://fr.yahoo.com/home/bf/*http://fr.biz.yahoo.com/fr_educ.html">Guide
de la finance</a></small></td>
<td align=right valign=top rowspan=2>
<a
href="http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/q?s=^FCHI&d=c&k=c4&t=1d"><img
border=0 width=192 height=96 src="http://ichart.lng.yahoo.com/t?s=^fchi"
alt=Cac40></a><br><small>[&nbsp;<a
href="http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/q?s=^FCHI&d=c&k=c3&a=m26-12-9&p=m50,m100&t=1y&l=on&z=m&q=l"><b>Graphiques
interactifs</b></a>&nbsp;]&nbsp;&nbsp;&nbsp;</small></td></tr>
<tr><td colspan=4 align=center><small><a
href="http://fr.yahoo.com/home/bf/*http://fr.biz.yahoo.com/euro.html"><b>Préparez-vous
au passage à l'euro</b></a></small></td></tr>
<tr><td height=4></td></tr></table></td></tr></table></td></tr><tr><td
height=4></td></tr></table><table border=0 cellspacing=0 cellpadding=4>
<tr><td valign=top nowrap><small>
<font size=3 face=arial><a href=ji><b>Actualités et médias</b></a><br></font><a
href=jj>Sujets d'actualité</a>, <a href=jk>Télévision</a>, <a href=cb>Journaux</a>
<br><br><font size=3 FACE=arial><a href=dx><b>Art et
culture</b></a><br></font><a href=cd>Littérature</a>, <a href=ce>Cinéma</a>, <a
href=cf>Musique</a>, <a href=cg>Musées</a>
<br><br><font size=3 FACE=arial><a href=ch><b>Commerce et
économie</b></a><br></font><a href=ka>B2B</a>, <a href=kb>Shopping</a>, <a
href=ci>Emploi</a>, <a href=db>Immobilier</a>
<br><br><font size=3 FACE=arial><a
href=kc><b>Divertissement</b></a><br></font><a href=ck>À voir</a>, <a
href=kd>Loteries</a>, <a href=ke>Humour</a>, <a href=kf>Sorties</a>
<br><br><font size=3 FACE=arial><a href=kg><b>Enseignement et
formation</b></a><br></font><a href=kh>Primaire</a>, <a href=ki>Secondaire</a>,
<a href=kl>Supérieur</a>
<br><br> <font size=3 FACE=arial><a href=kj><b>Exploration
géographique</b></a><br></font><a href=kk>Zones régionales</a>, <a
href=da>Europe</a>, <a href=dy>Pays</a>, <a href=dc>France</a>
<br><br><font size=3 FACE=arial><a href=dd><b>Informatique et
Internet</b></a><br></font><a href=df>Internet</a>, <a href=dg>Logiciels</a>, <a
href=dh>Matériel</a><br></small>
</td><td valign=top nowrap><small>
<font size=3 FACE=arial><a href=di><b>Institutions et
politique</b></a></font><br><a href=dj>Ministères</a>, <a href=ea>Droit</a>, <a
href=eb>Services publics</a>
<br><br><font size=3 FACE=arial><a href=ec><b>Références et
annuaires</b></a></font><br><a href=ed>Dictionnaires</a>, <a
href=ee>Annuaires</a>, <a href=ef>Bibliothèques</a>
<br><br><font size=3 FACE=arial><a href=dr><b>Santé</b></a><br></font><a
href=eh>Diététique</a>, <a href=ei>Médecine</a>, <a href=ej>Organismes</a>
<br><br> <font size=3 FACE=arial><a href=ek><b>Sciences et
technologies</b></a><br></font><a href=fa>Animaux</a>, <a
href=fb>Astronomie</a>, <a href=fc>Physique</a>
<br><br><font size=3 FACE=arial><a href=dz><b>Sciences
humaines</b></a><br></font><a href=fe>Archéologie</a>, <a href=ff>Histoire</a>,
<a href=fg>Économie</a>
<br><br> <font size=3 FACE=arial><a href=fh><b>Société</b></a><br></font><a
href=fi>Enfants</a>, <a href=fj>Gastronomie</a>, <a href=ga>Religion</a>
<br><br><font size=3 FACE=arial><a href=gb><b>Sports et
loisirs</b></a><br></font><a href=gc>Sports</a>, <a href=gd>Tourisme</a>, <a
href=ge>Auto/Moto</a>, <a href=gf>Jeux</a></small></td></tr>
<tr><td height=8 colspan=2></td></tr><tr><td align=center
colspan=2><small><b>Sites de&nbsp;: <a href=dal>Algérie</a> - <a
href=je>Belgique</a> - <a href=jf>Canada</a> - <a href=dma>Maroc</a> - <a
href=jg>Suisse</a> - <a href=dtu>Tunisie</a></b></small></td></tr><tr><td colspan=2>
<center>

<a
href="http://rd.yahoo.com/M=200048723.200440667.202128390.200173051/D=fr/S=15432978:PB/A=200188489/R=0/*http://shop.store.yahoo.com/cgi-bin/clink?compaq2fr+shopping:dmad/M=200048723.200440667.202128390.200173051/D=fr/S=15432978:PB/A=200188489/R=1/1007627556+http://us.rmi.yahoo.com/rmi/http://www.compaq.fr/rmi-unframed-url/http://www.compaq.fr/home.asp">
<img
src="http://eur.a1.yimg.com/eur.yimg.com/a/fr/compaq2/powerebywhite9530.gif"
alt="Compaq" border="0" width="95" height="30"></a>

</center>
</td></tr></table></td><td align=right valign=top>
<table bgcolor=#3366cc border=0 cellspacing=0><tr><td>
<table bgcolor=white cellpadding=2 cellspacing=0 border=0 width=200>
<tr><td align=center bgcolor=#e0d0b0><font face=arial
size=2><b>À&nbsp;la&nbsp;une</b></font></td></tr><tr><td><table width=100%
cellpadding=0 cellspacing=0 border=0>
<tr><td valign=top>&nbsp;<b>&#183;</b>&nbsp;</td><td><small><a
href=http://fr.yahoo.com/home/etranger/*http://fr.fc.yahoo.com/p/proche-orient.html>Gaza&nbsp;:
le fondateur du Hamas assign&eacute; &agrave; r&eacute;sidence</a>
</small></td></tr><tr><td valign=top>&nbsp;<b>&#183;</b>&nbsp;</td><td><small><a
href=http://fr.yahoo.com/home/etranger/*http://fr.fc.yahoo.com/a/asiecentrale.html>Le
conflit afghan</a> , <a
href=http://fr.yahoo.com/home/etranger/*http://fr.fc.yahoo.com/b/bonn.html>la
conf&eacute;rence de Bonn</a> et <a
href=http://fr.yahoo.com/home/etranger/*http://fr.fc.yahoo.com/w/wtcenquete.html>ben
Laden</a> </small></td></tr><tr><td
valign=top>&nbsp;<b>&#183;</b>&nbsp;</td><td><small><a
href=http://fr.yahoo.com/home/france/*http://fr.news.yahoo.com/politique/>Intervention
t&eacute;l&eacute;vis&eacute;e de L.&nbsp;Jospin,
&#171;&nbsp;probable&nbsp;&#187; candidat</a></small></td></tr><tr><td
valign=top>&nbsp;<b>&#183;</b>&nbsp;</td><td><small><a
href=http://fr.yahoo.com/home/france/*http://fr.fc.yahoo.com/d/dossiercorse.html>Paillotes&nbsp;:
prison ferme requise contre Bernard Bonnet</a> </small></td></tr><tr><td
valign=top>&nbsp;<b>&#183;</b>&nbsp;</td><td><small><a
href=http://fr.yahoo.com/home/culture/*http://fr.movies.yahoo.com/films/filmsdelasemaine.html>Cin&eacute;ma&nbsp;:
les films de la semaine</a></small></td></tr><tr><td
valign=top>&nbsp;<b>&#183;</b>&nbsp;</td><td><small><a
href=http://fr.yahoo.com/home/sport/*http://fr.sports.yahoo.com/>Sport</a>&nbsp;:
<a
href=http://fr.yahoo.com/home/sport/*http://fr.sports.yahoo.com/tennis/>Tennis</a>
&middot; <a
href=http://fr.yahoo.com/home/sport/*http://fr.sports.yahoo.com/foot/>Football</a></small></td></tr>
<tr><td align=right colspan=2><a href=bc><small><i>Tous les
titres...</i></small></a></td></tr></table></td></tr><tr><td align=center
bgcolor=#e0d0b0><font face=arial size=2><b>(pub)</b></font></td></tr>
<tr><td align=center>

<a
href="http://fr.rd.yahoo.com/M=200051568.200584302.202204614.200267896/D=fr/S=15432978:MKTP/A=200294417/R=0/*http://fr.promotions.yahoo.com/noel2001/g1.html"><img
src="http://eur.a1.yimg.com/eur.yimg.com/a/fr/gosport/fp1fnoloop.gif" width=180
height=140 border=0></a>
</td></tr>
<tr><td align=center bgcolor=#e0d0b0><font face=arial
size=2><b>Communautés</b></font></td></tr><tr><td><table cellpadding=0
cellspacing=0 border=0>
<tr><td valign=top>&nbsp;<b>&#183;</b>&nbsp;</td><td><small>Non, vous
n'&ecirc;tes pas seul... <a
href=http://fr.yahoo.com/home/comm/?http://fr.docs.yahoo.com/comm/>Voici&nbsp;les&nbsp;communaut&eacute;s
Yahoo!</a></small></td></tr>
</table></td></tr><tr><td align=center bgcolor=#e0d0b0><font face=arial
size=2><b>Et&nbsp;sur&nbsp;Yahoo!</b></font></td></tr><tr><td><table
cellpadding=0 cellspacing=0 border=0 width=100%>
<tr><td valign=top>&nbsp;<b>&#183;</b>&nbsp;</td><td><small><a
href=http://fr.yahoo.com/home/ency/*http://fr.encyclopedia.yahoo.com>Y!
Encyclop&eacute;die</a>&nbsp;: <a
href=http://fr.yahoo.com/home/ency/*http://fr.encyclopedia.yahoo.com/tdm/tdm_f_2885.html>Arts</a>,
<a
href=http://fr.yahoo.com/home/ency/*http://fr.encyclopedia.yahoo.com/tdm/tdm_f_1734.html>Sciences
sociales</a>, <a
href=http://fr.yahoo.com/home/ency/*http://fr.encyclopedia.yahoo.com/tdm/tdm_f_1083.html>&Eacute;tats
du monde</a></small></td></tr><tr><td
valign=top>&nbsp;<b>&#183;</b>&nbsp;</td><td><small><a
href=http://fr.yahoo.com/home/cars/*http://fr.cars.yahoo.com/>Yahoo! Auto</a> -
<a href=http://fr.yahoo.com/home/cars/*http://fr.cars.yahoo.com/csp/>les
nouveaut&eacute;s</a>, <a
href=http://fr.yahoo.com/home/cars/*http://fr.cars.yahoo.com/news.html>l'actu</a>,
<a
href=http://fr.yahoo.com/home/cars/*http://fr.cars.yahoo.com/news/essais.html>les
essais</a>, <a
href=http://fr.yahoo.com/home/cars/*http://fr.cars.yahoo.com/ip/it/>le
trafic</a>...</small></td></tr><tr><td
valign=top>&nbsp;<b>&#183;</b>&nbsp;</td><td><small><a
href=http://fr.yahoo.com/home/selection/*http://fr.docs.yahoo.com/selection/>Les
sites s&eacute;lectionn&eacute;s cette semaine par
Yahoo!</a></small></td></tr><tr><td
valign=top>&nbsp;<b>&#183;</b>&nbsp;</td><td><small><a
href=http://fr.yahoo.com/home/jobs/*http://fr.docs.yahoo.com/info/recrute.html>Yahoo!
recrute...</a> </small></td></tr>
<tr><td align=right colspan=2><a href=jh><small><i>Tout Yahoo!
France...</i></small></a></td></tr></table></td></tr></table></td></tr></table></td></tr></table><hr
size=1 noshade width=640><table border=0 cellspacing=0>
<tr><td align=center><small><a HREF=hc>Faites de Yahoo! France votre page
d'accueil sur le Web</a></small></td></tr>
<tr><td height=4> </td></tr><tr><td><small><b>Yahoo! dans le
monde</b></small></td></tr>
<tr><td nowrap><small><i>Europe&nbsp;:</i> <a href=de>Allemagne</a> · <a
href=dk>Danemark</a> · <a href=es>Espagne</a> · <a href=hs>Grèce</a> · <a
href=it>Italie</a> · <a href=no>Norvège</a> · <a href=uk>R.U. & Irlande</a> · <a
href=se>Suède</a></small></td></tr>
<tr><td nowrap><small><i>Asie&nbsp;:</i> <a href=nz>Australie & N.Z.</a> · <a
href=cy>Chine</a> · <a href=kr>Corée</a> · <a href=he>HK</a> · <a
href=in>Inde</a> · <a href=jp>Japon</a> · <a href=sg>Singapour</a> · <a
href=tw>Taiwan</a> · <a href=as>en anglais</a> · <a href=hk>en
chinois</a></small></td></tr>
<tr><td nowrap><small><i>Amériques&nbsp;:</i> <a href=co><b>Yahoo! [US]</b></a>
· <a href=ar>Argentine</a> · <a href=br>Brésil</a> · Canada ( <a href=cq>FR</a>
/ <a href=ca>EN</a> ) · <a href=mx>Mexique</a> · <a href=el>en
espagnol</a></small></td></tr><tr><td height=8>
</td></tr><tr><td><small><b>Autres services Yahoo!</b></small></td></tr>
<tr valign=top><td><small><i>Actualités&nbsp;:</i> <a href=bc>À la Une</a> · <a
href=mn>Monde</a> · <a href=fr>France</a> · <a href=lo>Local</a> · <a
href=eo>Économie</a> · <a href=mm>Multimédia</a> · <a href=sc>Sciences</a> · <a
href=sa>Santé</a> · <a href=jj>Dossiers</a></small></td></tr>
<tr valign=top><td><small><i>Finance&nbsp;:</i> <a href=bf>Bourse</a> · <a
href=bl>Banque en ligne</a> · <a href=ct>Conversion de devises</a> · <a
href=im>Impôts</a> · <a href=vi>Vidéo</a></small></td></tr>
<tr valign=top><td><small><i>Sport&nbsp;:</i> <a href=jd>À la Une</a> · <a
href=fo>Football</a> · <a href=fu>Formule 1</a> · <a href=te>Tennis</a> · <a
href=ru>Rugby</a> · <a href=bt>Basket</a> · <a href=cm>Cyclisme</a> · <a
href=sm>et aussi...</a></small></td></tr>
<tr valign=top><td><small><i>Culture/Loisirs&nbsp;:</i> <a href=mv>Cinéma</a> ·
<a href=mu>Musique</a> · <a href=pp>People</a> · <a href=bg>Horoscope</a> · <a
href=jx>Jeux</a> · <a href=bh>Logithèque</a> · <a href=tl>Programmes
Télé</a></small></td></tr>
<tr valign=top><td><small><i>Les sites à voir&nbsp;:</i> <a href=cs>Le choix des
surfeurs</a> · <a href=jb>Les nouveaux venus</a> · <a href=sl>Les sites de la
semaine</a></small></td></tr>
<tr valign=top><td><small><i>Services Yahoo!&nbsp;:</i> <a href=om>Les
communautés Yahoo!</a> · <a href=cp>Compagnon</a> · <a href=bj>Messenger</a> ·
<a href=jh><i>et aussi...</i></a></small></td></tr></table><hr size=1 noshade
width=640><small><a href=ha>Infos Yahoo!</a> · <a href=hb>Yahoo! Données
personnelles</a> · <a href=cu>Conditions d'utilisation</a> · <a href=gk>Suggérer
un site</a> · <a href=hd>Annoncer sur Yahoo!</a></small><p><small>Copyright © 
2001

Yahoo! Inc. Tous droits réservés.</small></form></center></body></html>
<!-- compressed -->

***********************************************************************
This works fine here with 2001-12-05-04 under W2K
Can you test with a recent build from here and report back:
  http://ftp.mozilla.org/pub/mozilla/nightly/latest/
Please attach a screenshot of what you describe to allow us better understand
what happens.
It seems to wfm with build 2001120504 on Win2k (at least, rendering identical to
what IE6 does).
Keywords: top100
Problem still occurs today (Mozilla 0.9.6 on NT) huge blank space in the middle
of the site fr.yahoo.com. 
On another PC (running Mozilla 0.9.6 on Win98 the site displays fine).

See screen shots in attachment (saved in RichTextFormat using MS Wordpad)
Reporter, create a new profile 'mozilla -profilemanager' and see if it fixes the
problem.
Hi

this morning I verified that the problem still existed (it did) and then
as suggested by cahagn_o@epita.fr I created a new profile. With the new
profile the display problem went away!

Must be something to do with the old profile....
Marking WORKSFORME as per reporter comments.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
OOPs - I was too quick on this.

I just reopened mozilla again this afternoon and went to the site
http://fr.yahoo.com/ and the problem is back again. (Big blank region in middle
of the site). (Problem does not occur for me with Mozilla on Linux or Win98).

It seems that recreating the profile fixed the problem temporarily but only for
the first time the browser was launched. Closing the browser and restarting
seems to have caused the problem to come back!

Any ideas what this could be? Maybe some kind of problem with cache?
reopening. 
Status: RESOLVED → UNCONFIRMED
Component: Browser-General → Networking: Cache
Resolution: WORKSFORME → ---
->cache (maybe layout)
Assignee: asa → gordon
QA Contact: doronr → tever
i cant seem to produce this problem with moz 0.9.8 (2002020406) on win2k, could
anyone else try with newer build
Works for me on 2002031104, W2K. Tried both the current live page and the source
as pasted in the original report, with several reloads.

William, do you still see this? If not, please resolve as WORKSFORME.
hehe, now the same happens to me since 0.9.9 and 2002031803, i guess i filed a
dupe of this bug, mine is bug 131555.
do you happen to have the same problems with amazon.de and ebay.de ?
Attached image Screenshot of amazon.de
attached 2 screenshots, keep an eye on the scrollbars ...
happens with latest nightly, totally clean install and new profile.
*** Bug 131555 has been marked as a duplicate of this bug. ***
very very weird, im back to the 0.9.9 release now, and the page works, but there
still appear some special character when i view the source in mozilla, with
ns/ie they aint there.
ns: FESAT...K<br>• Für den
moz: FESAT...K<br>• Für den
all pages WFM now with 2002040403 !!!!
WFM, too (2002042510, Win2k)
William, do you still see this bug?
This bug still reproducible for me on NT using Mozilla RC1 for windows. 

Please never paste long listings, this makes bugs unreadable. So I might have
missed something, but I tested the Yahoo! and the Hirschmann pages, they look
OK. Does anybody still see a problem with a current version? If so, please give
enough details to verify.

pi
still WFM with RC3
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
Build: 2002053012

Yet another WFM
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → WORKSFORME
its back, and its even happening on this page
2002120308 trunk win2k
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
It works for me (2002120408 on Win2k, so only one day after Michael's build).
Actually all URLs (also from duplicate bug 131555) work.
It's probably really something with the profile or cache.
Michael, can you try it with a new profile (only visit a page where this
happens) and then restart the browser to see if it gets bad after the first
restart as described in comment #7 ?
If not, maybe visit some sites you visited during the last few days before you
saw it again. Maybe one of them triggers the problem...
- create new profile
- browser goes to mozilla.org/start
- goto http://bugzilla.mozilla.org/show_bug.cgi?id=113779
- see HUUUUUUuuuge empty gap

marking the last line of comment #18 -- moz: FESAT...K shows its that line being
stretched down like 12k pixels
Using build 20021209

I tried the pages you said had display problems on Win98 and WinXP(not sp1) and
they display correctly.

Have you got the latest display drivers installed?

These pages were looked at 

www.yahoo.fr
www.amazon.de

Both popped up fine for me. I don't have NT anything to test on though.

bill
*** Bug 138419 has been marked as a duplicate of this bug. ***
*** Bug 187676 has been marked as a duplicate of this bug. ***
*** Bug 130675 has been marked as a duplicate of this bug. ***
Apart from the fact that I'm not sure if they are really all duplicates (similar
but not identical symptoms don't mean same illness), I want to state that duped
bug 187676 did mention the character encoding as a possible source of the
problem, which sounds not too strange since all those duped bugs feature lots of
central European (Swedish, Finnish, German,... - but not US) people and websites.

Therefore 'Cache' might not necessarily be the correct component.
Unfortunately Asa is not on the cc list to change it, but maybe somebody else
finds my words might make sense...

At least those who see this bug should try the proposals from bug 187676 (change
encoding) and report back if it changes anything. 
over to intl to investigate the encoding issue.
Assignee: gordon → smontagu
Component: Networking: Cache → Internationalization
Keywords: qawanted
QA Contact: tever → ylong
This now also happens with the following URL:

http://www.weather.com/outlook/travel/print/FIXX0002

There is no scandinavic characters in that page, but there is a "degrees" symbol
when displaying the temperature. It appears to me that some font metric property
of "special characters" is being reported wrong under some circumstances.
Incidently, this bug report itself now shows the same problem! Comment #118, at
the location of "moz: FESAT...K". After that piece of text in comment 118, there
is a HUGE vertical gap until the log continues. I'm seeing this with the latest
nightly build (2002010508).
That should be comment 18, not 118. And sorry for the spam.
Petrus, do you only see that error with ISO-8859-1 (as you said in bug 187676)?
Please try switching the encodings.
(You use "View - Character Coding" for that, don't you?)
For me it works (on Win2k, same build as you have).
Changing the character encoding doesn't fix this. It did however fix one of the
earlier problems I was seeing. As a side effect, none of the scandinavic
characters worked anymore, which is probably why the wrong layout was fixed too.

It should also be noted that when I select the text on the screen, there is a
large vertical selection under the last row of text, as if the characters on
that row are very very high.
Attached file Minimized testcase
This is taken from http://www.2of3.com/mozilla/bug01.html by Joe Amersdorfer
(linked from dupe bug 138419)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
- created a new profile
- problem is there with minimized testcase from #39 (thanks Simon!)
Changing character-encoding does nothing.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
- same testcase, no problem

The testcase is the code stripped down from http://dict.leo.org/ (which seemed
to own the bug, until Mozilla 1.3a).
Removing *anything* else now makes the bug disappear immediately!

afaik linux-users are totally unaffected by this bug.
Dupes -> Confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 149561 has been marked as a duplicate of this bug. ***
I have previously seen this problem, but now I have revisited all the mentioned
urls in Bug 149561 and also the ones in this bug, none of them show the bad page
layout any more for me!

Mozilla 1.2.1
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
I remember having this problem with old (around 1.0 or so) builds, too. But back
then, it was quite easy to get rid of it by removing one file (IIRC the XUL.mfl
or something like that). The fact that this "strategy" doesn't work with new
builds (1.3b and 2003021715 here) makes me believe that the recent problems are
indeed due to a new bug which just has similar symptoms (see comment #32).

On the other hand, I am quite sure that the problem hasn't got anything to do
with ISO-8859-* encodings. When you switch to UTF-8 (in the View / Character
Coding menu), all ISO-8859-encoded special characters become invalid and are
replaced by question marks, which doesn't lead to this strange problem. If you
transform an 8-bit into an UTF-8 page and display it as UTF-8, special
characters are again decoded correctly and produce the huge gaps.

I have got another theory: As the problem only appears when running Mozilla as a
non-privileged user, I tried around a bit and found out that everything works
fine if (and only if) the current user is member of the Administrators group.
However, I haven't yet managed to find out more: I have tried around a bit
granting full access to everybody on the registry and on the Mozilla directory,
but this didn't help. Probably a tool which logs all filesystem and registry I/O
requests would help to locate the problem very quickly.
Now thats funny...even this page (the bugreport) has a huge white gap in between
head and foot of the page. :(

I can not confirm that this has anything to do with user privileges. I run
Mozilla as administrator, as user in administrator group or as low level user
and see the same result.
The fact that the problem also appears on this page was already mentioned in
comment #25 and comment #27. :)

Which Mozilla version are you currently running?
Mozilla 1.3b
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
bug 189628 related ???
Michael: I'm sure #113779 is a duplicate. The screenshots posted there show the
same results from the same URLs (endless scroll, etc.). Symptoms are identical.
does this only happen to lines w/ umlauts characters (ä ö ü)?
Blocks: 184714, 189628, 194254
Keywords: intl
Summary: The site displays badly (lots of blank space between top and bottom of the page) and scroll bar acts strangely (?) → The site displays badly (lots of blank space) and scroll bar acts strangely (?)
*** Bug 189628 has been marked as a duplicate of this bug. ***
On <http://www.dingo.saar.de/mozbug1/>, there are some Screenshots made for Bug
189628. I pinpointed the problem down to the browser not displaying huge gaps,
but to enlarging the height of inline-text-links (<a href="">bla</a>); if the
texts before and after the gap are marked, the link goes down a huge way, as you
can see in the screenshots on the URL above.
*** Bug 194293 has been marked as a duplicate of this bug. ***
*** Bug 194254 has been marked as a duplicate of this bug. ***
Here's another web page that shows this behaviour:

http://pregnancy.about.com/library/blbabynames.htm
This bug is still existent in 1.4rc2 -- Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.4) Gecko/20030612 (clean new profile)

The minimized testcase as well as a lot of sites using umlauts or accents show
the described behaviour.

Since I have been annoyed with this error for quite a long time now and I
(sadly?) am no programmer, I tried my best to help narrow down the cause:

I tested the entire unicode character set using a script based on the testcase
and here are my results; rendering errors occur with:
- all control characters from 0 to 31 except for 9 (\t: tabulator), 10 (\n:
newline) and 13 (\r: carriage return) (this won't affect too many users)
- all high latin-1 characters from 161 to 255 except for 173 (&shy = soft hyphen).

Among the latter are not only all common vocals with accents and umlauts but
also characters like º§©®£¥² etc. This means that French speaking users will be
affected most by this bug (accents), followed by other western european users
(umlauts, etc.) and finally the rest of the world if they happen to find a buggy
link with characters like º§©®£¥² etc.

There is no difference using named entities (i.e. "&uuml;") or the unicode
version (i.e. "&#252;"); even if written plainly (i.e. "ü") the error occurs
(with the correct codepage selected).

Especially annoying is the case when there are several of these rendering errors
on one page, so that you cannot just scroll down completely and work your way up
from there to read the rest of the content. With more than one error (content -
bug - whitespace - content - bug - whitespace - content ...) it is quite
difficult to find content between two of the rendering bugs in the large amount
of whitespace.

As a german user I sadly have to say that this might be the main reason for me
not to use mozilla all the time (which I would really like to).

I'll upload my test script, but I can't guarantee that it will be working online
as it uses quite a lot of quickly programmed JavaScript. As a local file it
should work in any case.

A final question: Shouldn't this rather be a rendering bug than an
internationalisation bug?
Attachment #126410 - Attachment description: Unicode testcase using JavaScript → Testcase for detecting affected characters
Not only links (a-tags) but also other inline tags (b,i,u,em, etc.) can cause
the bug. The complete description is in the attachment file.

There seem to be two manifestations of this bug:
1. The relevant code is inserted into a table cell and right- or
center-aligned.
2. The text after the code (but on the same line) has to be wrapped.

I am hesitant to request a blocking 1.4 flag as it seems to late to do that.
But because Mozilla 1.4 is going to replace the 1.0 branch as the stable
development path I consider it important to squash this bug, as many webpages
(especially of international sites) are displayed erroneous and nearly
unreadable because of  it.

Not without reason this bug is flagged top100. Further examples would be
miscellaneous articles on important german newssites like spiegel.de or
heise.de.

I will also add two minimized testcases for above mentioned manifestations of
the bug.
Martin, it's great how much effort you put into this, but... I still just cannot
reproduce the problem in your testcases on Win2000 with 1.4rc1 and a CVS trunk
build from 0613, even using different profiles.
Did I miss something?
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030622

Neither can I, in the last two testcases I cannot see anything unexpected. Maybe
a screenshot will show what the difference is. Have you tried a new profile?

pi
Okay, you just made me completely wipe anything mozilla related (program and
profiles from all user accounts) from my harddrive only to reinstall 1.4rc3.

This is a long story, the bug seems to be still there. For the result just look
at the last paragraphs.

Here is what I found:

I reinstalled from the Windows 2000 Administrator account (into the normal
Windows 2000 directory: C:\Program Files\mozilla.org\Mozilla).

After installation I was asked if I wanted to migrate my old Netscape 4.7
Profile (I use Netscape 4.7 for testing webpages sometimes). I declined and
generated a clean new profile.

After starting Mozilla and testing all the testcases - no bug showed up.

Happily I signed off and logged in with my normal user account (no administrator
rights for security).

Same procedure there: starting Mozilla first time - migrate old profile? no -
create new profile? yes. Looking at the testcases - the bug was THERE AGAIN.

Switching back to the Administrator account: no bug there. Back at my user
account: bug.

To be sure I created a completely new Windows 2000 user (without administrator
rights).  After creating a new profile for this user the bug showed up there too.

Then I added the new user to the Administrators group. Logging off and on with
the new user I had a look at the testcases: the bug WAS GONE. After removing the
new user from the Administrators group the bug was THERE AGAIN.

Conclusion:

The bug seems to depend on user rights. It doesn't show up with users in the
Administrators group; other users can see the bug. I don't know if this is the
cause because of normal users having no write rights in the installation
directory or some registry issue or something completely different. But I can
reproduce it every time.
I'm sorry, Martin, but I'm a member of the administrator group on my system and 
I can still see the bug sometimes. I can't imagine there's a coherence.

The bug occurs if the computer has been running for some days and user log on 
and off the System and start and stop Mozilla a couple of times. Once the bug 
occurs, it "survives" restarting Mozilla and occurs even if you log off and on 
again. You have to restart the computer to geet rid of it.

To me with my simple programming knowledge, this looks like a integer overflow 
(or underflow or something like this) during calculation of an elements height. 

Just an idea: Add some debug code that creates a log file from the rendering 
process, including all element heights. If the bug occurs, one can enable these 
logging procedures and the log file may help the developers to track this issue 
down.
Martin, impressive work. One hint for the future: You don't need to delete
profiles to test new profiles. It may be a good idea to completely (maybe except
for plugins) delete the program directory as you did, though.

Now Jan says that admin alone is not a factor. And actually with Linux I don't
see problems either. So there is a chance for more testing here. If you have
these frech profiles as admin and as user, they should look very similar. You
can compare those (prefs.js for a start) and see what the difference is. Maybe
you can find one option which makes the difference.

pi
Hey, no need to be sorry for me. I'll cope. :-) It's my favourite bug as it
annoys me most of all.

So I'm trying to pinpoint the cause, as it's obviously still there (sometimes). 

All I can say is that all my local non-administrator users encounter this bug
even after a fresh reboot. I'm not working a lot logged in as administrator (I
do now) so I cannot say if the bug occurs also for administrators after some
time. At the moment it does not. However, WHEN the bug occurs, my testcases can
confirm it.

So this bug seems to appear when:
1. "something" inside Mozilla has become "corrupted" (please forgive the
   unprofessional vague term), which may for example be the cause if a user
   has no administrator rights (my problem) or "if the computer has been
   running for some days and users log on and off the System and start and
   stop Mozilla a couple of times" (described in the comment #64
   by Jan) AND
2. the HTML sourcecode of a page contains some code as described in 
   http://bugzilla.mozilla.org/attachment.cgi?id=126482&action=view

Jan pointed out the reason for the "corruption" may be an integer
overflow/underflow and suggests that one should debug the calculation of
elements heigth. If someone adds this debugging code (I would if I could), I
would gladly log all occurences (I have lots of them, any time :-/ ) and post
the logfiles here.

I will try to compare the mozilla profiles from the administrator and user
accounts as suggested by Boris in #65 later this day. (Oh, and I kept a backup
of my deleted profiles of course, Boris. So no need to worry.)
I just compared the two profiles (administrator / user) and found no noticable
differences.

As I think about it, this was going to be expected:

After all - like I described in #63 - the same user with exactly the same
profile does not encounter the bug while member of the administrators group, but
has to face it when he is not a member. So the bug doesn't seem to be (mozilla)
profile related. Maybe it's Windows 2000 profile related? (Please don't make me
compare these!)
Martin, I just tried rc3 on Win2k with a non-admin account and still could not
reproduce this bug.
(However, months ago I also had it from time to time, so of course I have no
doubt this bug is valid.)

The story goes as this: 
Created a new user, logged in as him, created a new profile for an existing Moz
installation, tried, no bug.
Then downloaded rc3 installer (I use the zipfiles usually), tried to install, it
said I should be Admin, so logged into admin, installed it into standard path,
logged into test user, created another profile, tried, no bug.
Tried again with previously created profile, also no bug.
Well...

But carry on with your work, I can feel you are getting closer!
Not sure what this bug is even doing in internationalisation. Judging by the
last comments it seems more like HTML Frames or views.
Assignee: smontagu → roc+moz
Component: Internationalization → Layout: View Rendering
QA Contact: ylong → ian
Now it happended: I can't reproduce the bug anymore.

Never change a buggy system...

I don't know what exactly caused the bug to go away, but the "corruption" I
mentioned in comment #66 seems to be gone.

I don't think anything I recall I did caused the bug to vanish, but here are the
actions I can remember for the record anyway:

First of all I decided to analyze the differences between a bug-free profile (my
administrator account) and a profile with bug (my test user) also regarding file
and registry access.

On each account I started filemon.exe and regmon.exe (from sysinternals.com),
fired up mozilla and went to http://dict.leo.org/ (my "favourite" bug page).
Then I saved the log files of filemon and regmon.
I repeated this several times.

Finally, using awk and diff, I created diff files showing the differences in
file and registry access. The resulting files were quite a mess to me, but I
noticed, that the non privileged test user got some errors trying to open a font
file which worked for the administrator user.
Taking a wild guess (as I didn't know where to start) I made the windows 2000
font directory (C:\WinNT\Fonts) writable for any user.

I started mozilla from the test user account and - the bug was gone. So I
revoced the write access for any user from the Fonts directory, to determine if
the bug would reappear. It didn't. Even better yet: the bug was gone for all
other non privileged users as well.

If this action would really be the cause of the disapperance of the bug it would
mean that mozilla running as non privileged user did some one time action to the
fonts directory to the benefit of all other non privileged users. I don't
believe that this is true.

Sadly, now I won't be able to keep my promise made in comment #66 that I would
generate debug logs if someone would integrate a function for this.

On the other hand I'm happy the bug is gone for me now, but I have the feeling
it will return just when I am least expecting it...
What font file was it? Or were there several with errors?
And: do these errors still occur if you do the same test with the re-restricted
privileges?

It's really not my territory, but in my colorful phantasy I could imagine that
Mozilla tries to access a (different?) font for the special characters, cannot
open it, but still uses font metrics (e.g. height) from it - based on nonsense
data because the font could not be opened. Hence the irrational height.
(Would that be a hint what numbers to debug?)
Some sort of caching of fonts or font metrics (does such a thing exist??) might
explain why the bug did not appear once the font had been read.
Or everything in the last paragraph is pure nonsense.

Maybe new profiles or even better a fresh installation might show if some
caching occurs.

What data is stored in registry.dat? It is not profile-specific... are there
other places for such data? Maybe in the application dir or the Windows registry?
Good news: I got my bug back! I made it magically reappear! 

In earnest now: My wild guess in comment #70 seems to be not so wild at all.

I remembered my file access logs from yesterday (comment #70); these show which
files mozilla accesses during startup and opening http://dict.leo.org/. I
created a new one today (without bug) and compared it with the one from
yesterday (with bug).

I noticed some strange behaviour:

The bug infested log from filemon has 17 lines of:
IRP_MJ_CREATE             C:\WINNT\FONTS\LIMOU___.TTF ACCESS DENIED

The bug free log contains the lines:
IRP_MJ_CREATE                   C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
FASTIO_QUERY_STANDARD_INFO      C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
FASTIO_QUERY_BASIC_INFO         C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
IRP_MJ_QUERY_VOLUME_INFORMATION C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
FASTIO_QUERY_STANDARD_INFO      C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
IRP_MJ_CLEANUP                  C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
IRP_MJ_CLOSE                    C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
IRP_MJ_CREATE                   C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
FASTIO_QUERY_STANDARD_INFO      C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
FASTIO_QUERY_BASIC_INFO         C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
IRP_MJ_QUERY_VOLUME_INFORMATION C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
FASTIO_QUERY_STANDARD_INFO      C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
IRP_MJ_CLEANUP                  C:\WINNT\FONTS\LIMOU___.TTF SUCCESS
IRP_MJ_CLOSE                    C:\WINNT\FONTS\LIMOU___.TTF SUCCESS

Mozilla reads three font files completely unrelated to any opened web page while
loading the first web page after startup. For example ENLIVEN.TTF, FRNKVENT.TTF
and MICROSS.TTF. If one of these files can not be read at this time the bug occurs.

If you remove one of these files from the font directory and restart Windows
2000, Mozilla will try to load some other fonts next time. I guess Windows 2000
recreates a font table to select from on every reboot.

I simply revoked read access to the file or removed it from the font directory
to make the bug occur.
Regranting read access or copying back the font file made the bug go away (after
restarting Mozilla).

But there might be plenty of other causes why the font file cannot be read:
* It is exlusively opened by another task.
* Perhaps the format of the font file is corrupted and Mozilla (or Windows
2000?) can not handle that. (I read many ttf files, especially not well tested
downloads from the web, are corrupted.)
* Finally: Have you ever noticed how Windows 2000 becomes really edgy about
loading new fonts after it has been running for some time (especially if the
memory is getting low)? This might explain behaviour like it is described in
comment #64. Restarting Windows 2000 will make the bug go away (for some time). 

My questions are:

- Why does mozilla try to read these strange fonts at all? 
- Should other fonts be read instead?
- Is that a font indexing problem?
- Is there anything like a font table or cache (in Mozilla or Windows 2000)?

I guess:
1. Mozilla tries to read data from wrong or unnnecessary font files.
2. If it can't get the data this messes up the font metrics.
3. This causes wrong rendering in special cases (described in comment #58).

Perhaps the font access error is not a Mozilla but a Windows 2000 bug. But this
doesn't explain why these files are read in the first place. If the files have
to be read but cannot be accessed, Mozilla should make sure not to corrupt it's
font metrics.
Just some information that might be useful too:

The "wrong fonts" (comment #70) are read by Mozilla only when a page containing
the "special characters" (comment #56) is opened. So there seems to be a problem
in judging which font (data) to use for the special character.

On a different note: The bug appears also while printing web pages. The extra
whitespace is *really* annoying, especially if there are more than one
occurences (imagine a lot of blank or semi-printed pages).
According the MSDN documentation, those IRP_MJ_CREATE...IRP_MJ_CLOSE pairs are
notifications about getting file handles and reading the data.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k113_02lu.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/w98ddk/hh/w98ddk/kstream_6db9.asp

>- Why does mozilla try to read these strange fonts at all? 

How can Mozilla magically know that a font file is "unnecessary" / "wrong"/
"corrupted"? What Mozilla does is to _attempt_ to see the characters that are in
the fonts advertised by the OS. Then if an error occurs, it (gracefully) tries
other fonts, until if finds a font that the OS says is OK to use.

>- Should other fonts be read instead?

Mozilla does that (the point is that there must be a sequence somewhere to get
there...).

>- Is that a font indexing problem?
>- Is there anything like a font table or cache (in Mozilla or Windows 2000)?

Mozilla (and the OS) have their font cache. Mozilla just caches some brief
metadata about the font (to quickly meet layout demands), while the OS might be
caching other OS/GDI-related stuff.

From your investigation, looks like something is out of sync somewhere, but I
have been unable to reproduce. I was guessing that maybe Mozilla was instructed
that a font was available, and so put its metadata in its cache. But when came
the time to check out the font, the OS denies access (perhaps because the font
file has been "exlusively opened by another task" in the meantime). But this is
similar to failing to open a file and there is code to handle such failures
gracefully.

Here is what I did to attempt to reproduce (on Win2K):
1) launch Mozilla and goto http://www.yahoo.fr (or http://dict.leo.org/)
   (both render fine for me)
2) now goto Windows Start -> Settings -> Control Panel -> Fonts
   locate "Microsoft Sans Serif Regular" (which is MICROSS.TTF --
   I don't have the ENLIVEN.TTF & FRNKVENT.TTF that you mentioned).
3) right-click on the font name to bring the context menu and select the
   Properties -> Security dialog
4) change all the Read permissions to Denny, for all kind of users...
5) hit reload in Mozilla
   still renders fine here.

What am I missing?!?
Roger, it's not quite so easy to find the fonts mozilla is trying to read. These
fonts seem to depend on your installed font files. As I said before, if you
remove one of the font files mozilla was openening (and restart Windows 2000) it
will load a number of completely different fonts.

I'll try to give introductions now to reproduce the bug. It will be easiest for
you if you use an administrator account to test this. You may also want to set
your Mozilla startup page to blank, to cut down on the number of opened files.

1. First of all you have to find out which font files Mozilla is reading 
   whenever it has to render content with some "special characters". So you have 
   to keep track of the files opened by Mozilla.

2. A tool that is capable of this task is Filemon from Sysinternals. Get it from 
   http://www.sysinternals.com/ntw2k/source/filemon.shtml
   Install this small utility. (It's less than 200k.)
   
3. Make sure Mozilla is not running at the moment.

4. Run filemon.exe. If you are not running with administator privileges then run 
   it as user Administrator (Shift-Rightclick -> Run as...). A filter dialogue 
   will come up. Put "mozilla.exe:" in the Include field and "font" in the 
   Highlight field (both without quotes). Okay.
   
5. Now fire up Mozilla and immediately go to http://dict.leo.org/.

6. Switch over to Filemon. Note that some lines containing TIMESI.TTF are marked 
   red. Mozilla needs this font file as there are some italics on that page.
   
7. Scroll up a little bit until you get to a huge red block with consecutive 
   font files in the path column. In my case these are 
   C:\WINNT\FONTS\ITALI___.TTF, EMMETT__.TTF, ENLIVEN_.TTF and FRNKVENT.TTF, 
   each font reoccuring 10 times of the log. Remember the name of these font 
   files because your files will be different from mine and you can't test the 
   bug just using the fonts from my example.
   
8. Use explorer to change the access privileges for one of the files to deny the 
   current user read access or move the file out of the font directory. An easy 
   way to get to the font directory is doubleclicking one of the lines of the 
   block containing the fonts.

9. Close Mozilla.
   
10. Start Mozilla, visit http://dict.leo.org/ or any of the testcases.

11. Render bug!

12. To make the bug disappear again regrant read access or move the file back to 
   the font directory and start Mozilla again. If the bug chooses to stay: 
   Moving the file out of the font directory, restarting Windows 2000 and moving 
   the file back worked for me.

I hope this will make the bug occur for you as well.
Ah, that should be instructions and not introductions.
yep, the steps above did the trick...

Below is a stack trace which gives an indication as to what is happening (with
http://dict.leo.org/):

1) nsTextFrame asks to measure a string, but the problem is: the first character
is the null char \0, and yet the length of the string is non-zero. 

2) Since Gfx trusts the length, it proceeds to scan the string, to find a font
which has a glyph for the first char (the null char that it didn't check...). 

3a) First case (i.e., when no font has been 'denied' yet), the find fails, and
Gfx falls back to the substitute font which detects with its brute force that
'\0' is nothingness, returns 0, and so the end-user doesn't see any ill-effect.

3b) Second case (i.e., when a font has been 'denied'), the find in
FindGlobalFont curiously reports now a matching font in the system.

4) And when passing the null char \0 to the OS function that does measurement
(it returns without filling the OUT params..), which leads to some
random/garbage value.


Two enigmatic questions:
1) why does nsTextFrame pass a string with null chars?
2) why does the OS report that a font has the null char when 'deny' is in effect?

For #2, it apparently seems that something goes out-of-sync in th OS cache here,
but #1 is definitely something to be addressed on Mozilla's side, either as a
palliative (init the OUT params...) or a deeper investigation to find out why
the indices in nsTextFrame sometimes point to null chars. 


stack trace
========================
nsFontMetricsWin::FindGenericFont(HDC__ * 0x01010054, unsigned int 0) line 3363
+ 35 bytes
nsFontMetricsWin::FindFont(HDC__ * 0x01010054, unsigned int 0) line 3460 + 19 bytes
nsFontMetricsWin::LocateFont(HDC__ * 0x01010054, unsigned int 0, int & 1) line
3852 + 16 bytes
nsFontMetricsWin::ResolveForwards(HDC__ * 0x01010054, const unsigned short *
0x0012b24c, unsigned int 7, int (const nsFontSwitch *, const unsigned short *,
unsigned int, void *)* 0x025cc510 do_GetTextDimensions(const nsFontSwitch *,
const unsigned short *, unsigned int, void *), void * 0x0012ad58) line 3906 + 25
bytes
nsRenderingContextWin::GetTextDimensions(nsRenderingContextWin * const
0x036d6fb0, const unsigned short * 0x0012b24c, unsigned int 7, nsTextDimensions
& {...}, int * 0x00000000) line 2212
nsTextFrame::MeasureText(nsIPresContext * 0x032a5818, const nsHTMLReflowState &
{...}, nsTextTransformer & {...}, nsILineBreaker * 0x03772148,
nsTextFrame::TextStyle & {...}, nsTextFrame::TextReflowData & {...}) line 5169
nsTextFrame::Reflow(nsTextFrame * const 0x0378debc, nsIPresContext * 0x032a5818,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 5459 + 43 bytes
nsLineLayout::ReflowFrame(nsIFrame * 0x0378debc, unsigned int & 0,
nsHTMLReflowMetrics * 0x00000000, int & 0) line 1031 + 43 bytes
nsInlineFrame::ReflowInlineFrame(nsIPresContext * 0x032a5818, const
nsHTMLReflowState & {...}, nsInlineFrame::InlineReflowState & {...}, nsIFrame *
0x0378debc, unsigned int & 0) line 731 + 22 bytes
nsInlineFrame::ReflowFrames(nsIPresContext * 0x032a5818, const nsHTMLReflowState
& {...}, nsInlineFrame::InlineReflowState & {...}, nsHTMLReflowMetrics & {...},
unsigned int & 0) line 545 + 28 bytes
nsInlineFrame::Reflow(nsInlineFrame * const 0x0378de58, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 454 + 28 bytes
nsLineLayout::ReflowFrame(nsIFrame * 0x0378de58, unsigned int & 0,
nsHTMLReflowMetrics * 0x00000000, int & 0) line 1031 + 43 bytes
nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & {...}, nsLineLayout &
{...}, nsLineList_iterator {...}, nsIFrame * 0x0378de58, unsigned char *
0x0012ba6c) line 3712 + 22 bytes
nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & {...}, nsLineLayout &
{...}, nsLineList_iterator {...}, int * 0x0012c178, unsigned char * 0x0012bf40,
int 0, int 0) line 3579 + 32 bytes
nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState & {...},
nsLineList_iterator {...}, int * 0x0012c178, unsigned char * 0x0012bf40, int 0,
int 0) line 3481 + 46 bytes
nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & {...}, nsLineList_iterator
{...}, int * 0x0012c178, int 0, int 0) line 3425 + 36 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineList_iterator {...},
int * 0x0012c178, int 0) line 2535 + 33 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2181 + 31 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x0378da4c, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 849 + 15 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x0378da4c, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int
15, int 15, unsigned int 0, unsigned int & 0) line 949 + 31 bytes
nsTableCellFrame::Reflow(nsTableCellFrame * const 0x0378d97c, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 919
nsContainerFrame::ReflowChild(nsIFrame * 0x0378d97c, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int
735, int 0, unsigned int 0, unsigned int & 0) line 949 + 31 bytes
nsTableRowFrame::ReflowChildren(nsTableRowFrame * const 0x0378d078,
nsIPresContext * 0x032a5818, nsHTMLReflowMetrics & {...}, const
nsHTMLReflowState & {...}, nsTableFrame & {...}, unsigned int & 0, int 0) line
1046 + 45 bytes
nsTableRowFrame::Reflow(nsTableRowFrame * const 0x0378d078, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 1456 + 37 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x0378d078, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0,
int 0, unsigned int 0, unsigned int & 0) line 949 + 31 bytes
nsTableRowGroupFrame::ReflowChildren(nsTableRowGroupFrame * const 0x0377177c,
nsIPresContext * 0x032a5818, nsHTMLReflowMetrics & {...}, nsRowGroupReflowState
& {...}, unsigned int & 0, nsTableRowFrame * 0x00000000, int 0, nsTableRowFrame
* * 0x00000000, int * 0x0012ced0) line 425 + 45 bytes
nsTableRowGroupFrame::Reflow(nsTableRowGroupFrame * const 0x0377177c,
nsIPresContext * 0x032a5818, nsHTMLReflowMetrics & {...}, const
nsHTMLReflowState & {...}, unsigned int & 0) line 1315 + 35 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x0377177c, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0,
int 30, unsigned int 0, unsigned int & 0) line 949 + 31 bytes
nsTableFrame::ReflowChildren(nsTableFrame * const 0x037715a4, nsIPresContext *
0x032a5818, nsTableReflowState & {...}, int 1, int 0, unsigned int & 0, nsIFrame
* & 0x00000000, int * 0x00000000) line 3270 + 50 bytes
nsTableFrame::ReflowTable(nsIPresContext * 0x032a5818, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, int 1073741824, nsReflowReason
eReflowReason_Resize, nsIFrame * & 0x00000000, int & 0, int & 1, unsigned int &
0) line 2194
nsTableFrame::Reflow(nsTableFrame * const 0x037715a4, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 2053
nsContainerFrame::ReflowChild(nsIFrame * 0x037715a4, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0,
int 0, unsigned int 3, unsigned int & 0) line 949 + 31 bytes
nsTableOuterFrame::OuterReflowChild(nsTableOuterFrame * const 0x03771438,
nsIPresContext * 0x032a5818, nsIFrame * 0x037715a4, const nsHTMLReflowState &
{...}, nsHTMLReflowMetrics & {...}, int 12465, nsSize & {...}, nsMargin & {...},
nsMargin & {...}, nsMargin & {...}, nsReflowReason eReflowReason_Initial,
unsigned int & 0) line 1335 + 47 bytes
nsTableOuterFrame::Reflow(nsTableOuterFrame * const 0x03771438, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 2017 + 74 bytes
nsBlockReflowContext::ReflowBlock(const nsRect & {x=0 y=15 width=12465
height=1073741824}, int 1, nsCollapsingMargin & {...}, int 0, nsMargin & {...},
nsHTMLReflowState & {...}, unsigned int & 0) line 543 + 42 bytes
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineList_iterator
{...}, int * 0x0012df1c) line 3191 + 56 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineList_iterator {...},
int * 0x0012df1c, int 1) line 2399 + 27 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2181 + 31 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x03770dc4, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 849 + 15 bytes
nsBlockReflowContext::ReflowBlock(const nsRect & {x=0 y=0 width=12705
height=1073741824}, int 1, nsCollapsingMargin & {...}, int 1, nsMargin & {...},
nsHTMLReflowState & {...}, unsigned int & 0) line 543 + 42 bytes
nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineList_iterator
{...}, int * 0x0012ea74) line 3191 + 56 bytes
nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineList_iterator {...},
int * 0x0012ea74, int 1) line 2399 + 27 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2181 + 31 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x03770c6c, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 849 + 15 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x03770c6c, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0,
int 0, unsigned int 0, unsigned int & 0) line 949 + 31 bytes
CanvasFrame::Reflow(CanvasFrame * const 0x0374e780, nsIPresContext * 0x032a5818,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 588
nsBoxToBlockAdaptor::Reflow(nsBoxLayoutState & {...}, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0, int 0, int 0, int 12705, int 7170, int 1) line 899
nsBoxToBlockAdaptor::DoLayout(nsBoxToBlockAdaptor * const 0x03770bdc,
nsBoxLayoutState & {...}) line 643 + 46 bytes
nsBox::Layout(nsBox * const 0x03770bdc, nsBoxLayoutState & {...}) line 1048
nsScrollBoxFrame::DoLayout(nsScrollBoxFrame * const 0x0374eae4, nsBoxLayoutState
& {...}) line 356
nsBox::Layout(nsBox * const 0x0374eae4, nsBoxLayoutState & {...}) line 1048
nsContainerBox::LayoutChildAt(nsBoxLayoutState & {...}, nsIBox * 0x0374eae4,
const nsRect & {x=0 y=0 width=12705 height=7170}) line 650 + 16 bytes
nsGfxScrollFrameInner::LayoutBox(nsBoxLayoutState & {...}, nsIBox * 0x0374eae4,
const nsRect & {x=0 y=0 width=12705 height=7170}) line 1204 + 17 bytes
nsGfxScrollFrameInner::Layout(nsBoxLayoutState & {...}) line 1354
nsGfxScrollFrame::DoLayout(nsGfxScrollFrame * const 0x0374e9c8, nsBoxLayoutState
& {...}) line 1212 + 15 bytes
nsBox::Layout(nsBox * const 0x0374e9c8, nsBoxLayoutState & {...}) line 1048
nsBoxFrame::Reflow(nsBoxFrame * const 0x0374e990, nsIPresContext * 0x032a5818,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 886
nsGfxScrollFrame::Reflow(nsGfxScrollFrame * const 0x0374e990, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 836 + 25 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x0374e990, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0,
int 0, unsigned int 0, unsigned int & 0) line 949 + 31 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x0374e674, nsIPresContext *
0x032a5818, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...},
unsigned int & 0) line 262 + 43 bytes
IncrementalReflow::Dispatch(nsIPresContext * 0x032a5818, nsHTMLReflowMetrics &
{...}, const nsSize & {...}, nsIRenderingContext & {...}) line 917
PresShell::ProcessReflowCommands(int 1) line 6646
ReflowEvent::HandleEvent() line 6491
HandlePLEvent(ReflowEvent * 0x03795ef8) line 6505
PL_HandleEvent(PLEvent * 0x03795ef8) line 671 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00e22f90) line 606 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0003011e, unsigned int 49367, unsigned int 0,
long 14823312) line 1412 + 9 bytes
USER32! 77e3a244()
USER32! 77e145e5()
USER32! 77e1a792()
nsAppShellService::Run(nsAppShellService * const 0x0141bdb8) line 479
main1(int 1, char * * 0x00262698, nsISupports * 0x00ddafd0) line 1291 + 32 bytes
main(int 1, char * * 0x00262698) line 1670 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77ea847c()
Component: Layout: View Rendering → Layout: Fonts and Text
"a better safe than sorry patch"

I found this by trial and error. In principle when there is an error, the GDI
GetLastError() function should report an extended code for that error. 

It turns out that it returns a different value from the ealier failure code
(surprisingly, lastError was 0-SUCCESS in my testing). Since to distinguish
between TrueType and bitmap fonts, GfxWin was piggy-backing exactly at that
_point_ on a specific error code (something undocumented in the MSDN docs), it
started doing strange things based on a false assumption.

As to the other reason why nsTextFrame is passing a null char, it is something
to be investigated, but it seems that this palliative patch does the trick in
the meantime. Note that this patch itself is piggy-backing on the fact that
GetLastError() contradicts an earlier failure code.
Comment on attachment 126668 [details] [diff] [review]
patch to detect when GDI is out-of-sync

good candidate for 1.4f
(noted that the bug is present in Nav 7.02)
Attachment #126668 - Flags: superreview?(roc+moz)
Attachment #126668 - Flags: review?(roc+moz)
Comment on attachment 126668 [details] [diff] [review]
patch to detect when GDI is out-of-sync

retracting the patch. a limitation is that it also blocks legitimate bitmap
fonts.
Attachment #126668 - Attachment is obsolete: true
Attachment #126668 - Flags: superreview?(roc+moz)
Attachment #126668 - Flags: review?(roc+moz)
Attached patch patch v2 (obsolete) — Splinter Review
As with the earlier patch, the idea is to avoid a hasty conclusion based solely
on GetFontData(). Since the OS has cached the font information aggressively,
the GDI functions seem to succeed and the problem is to find a cheap way to to
tell if a font is still usable or not, until the measuring/drawing stage where
it is too late... So I tried (again trial-and-error), certain font metrics
functions that might have the desirable side-effect of causing the OS to check
back to the file. Apparently, GetTextMetrics does that (in this context). It
returned a failure for font files that became inaccessible. As far as I could
test (on my Win2K box), this patch did the job without the earlier side-effect
of blocking legitimate bitmap fonts.
Attachment #126673 - Flags: superreview?(roc+moz)
Attachment #126673 - Flags: review?(roc+moz)
Same principle as previous patch. And some comments to help readability (to
make it clear why the specific 'error' was/is 'meaningful' at that point).
Attachment #126673 - Attachment is obsolete: true
Attachment #126673 - Flags: superreview?(roc+moz)
Attachment #126673 - Flags: review?(roc+moz)
Attachment #126723 - Flags: superreview?(roc+moz)
Attachment #126723 - Flags: review?(roc+moz)
Comment on attachment 126723 [details] [diff] [review]
better and more readable patch

ah, sweet. r+sr=roc+moz
Attachment #126723 - Flags: superreview?(roc+moz)
Attachment #126723 - Flags: superreview+
Attachment #126723 - Flags: review?(roc+moz)
Attachment #126723 - Flags: review+
Checked in. Marking FIXED, but some day if time permits, I might dig the
nsTextFrame side of ths story.
Assignee: roc+moz → rbs
Comment on attachment 126723 [details] [diff] [review]
better and more readable patch

Seeking a= for this patch which improves the safety of GfxWin when the status
of fonts change underneath Gecko (e.g., availability deny due to exclusive read
of the font by another application).
Attachment #126723 - Flags: approval1.4?
fixed-on-trunk
Status: NEW → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
rbs: Is there a bug# for the nsTextFrame thing?
Thanks to Martin and rbs for their investigative work on this annoying bug. :)

Whats with bug 184714? I think it addresses the same issue and may now be
resolved as well.
*** Bug 184714 has been marked as a duplicate of this bug. ***
re: comment #87

There is not yet a bug. Feel free to open another. I felt this one was already
too crowded and not really appropriate for the dreaded nsTextFrame, considering
that the bad layout problem itself is already fixed.
Martin, you rock! :-)

Can you verify that the problem is fixed? Not that I don't trust rbs, it's
just... you did not comment on the patch yet and you probably know best how to
reproduce the bug (and thus how to verify it's gone)...
Comment on attachment 126723 [details] [diff] [review]
better and more readable patch

moving approval request forward.
Attachment #126723 - Flags: approval1.4? → approval1.4.x?
*** Bug 179544 has been marked as a duplicate of this bug. ***
*** Bug 207821 has been marked as a duplicate of this bug. ***
*** Bug 205345 has been marked as a duplicate of this bug. ***
*** Bug 212386 has been marked as a duplicate of this bug. ***
*** Bug 211558 has been marked as a duplicate of this bug. ***
*** Bug 157703 has been marked as a duplicate of this bug. ***
*** Bug 214739 has been marked as a duplicate of this bug. ***
*** Bug 215020 has been marked as a duplicate of this bug. ***
Hey rbs, can you land this on the 1.4.1 branch for us? Consider drivers approval
granted
Attachment #126723 - Flags: approval1.4.x? → approval1.4.x+
Checked in the 1.4.1 branch.
Keywords: fixed1.4.1
*** Bug 171054 has been marked as a duplicate of this bug. ***
Blocks: 224532
*** Bug 155689 has been marked as a duplicate of this bug. ***
*** Bug 211840 has been marked as a duplicate of this bug. ***
I have found this bug once again in Mozilla Firefox, version 0.9.2
Steps to reproduce? You have to be more careful when awaking old demons like that.
Please see the 'Description' above to read the steps to reproduce.
It seems that this bug is not solved in Mozilla Firefox, only in Mozilla.
I am aware of that. I was asking for any new information you may have. It WFM on
my Firefox build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040707 Firefox/0.9.2.

Technically this was a bug fixed in the Gecko engine itself (I am the one who
fixed it). The difference Firefox vs Seamonkey is immaterial here. So you may be
seing another bug instead.
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: