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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: wstinson, Assigned: rbs)
References
()
Details
(Keywords: fixed1.4.1, intl, top100)
Attachments
(9 files, 2 obsolete files)
381.25 KB,
application/rtf
|
Details | |
23.59 KB,
image/png
|
Details | |
26.31 KB,
image/png
|
Details | |
152 bytes,
text/html
|
Details | |
5.23 KB,
text/html
|
Details | |
5.82 KB,
text/html
|
Details | |
102 bytes,
text/html
|
Details | |
93 bytes,
text/html
|
Details | |
1.12 KB,
patch
|
roc
:
review+
roc
:
superreview+
roc
:
approval1.4.1+
|
Details | Diff | Splinter Review |
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é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> <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> <a href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/>Yahoo! Voyages</a> : <a href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/loc/>Offres sports d’hiver</a> <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> · <a href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/flights/>Billets d’avion</a> <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> · <a href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/affaires/>Bonnes affaires</a> <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 :</b> <a href=bc>Actualités</a> · <a href=bf><b>Finance</b></a> · <a href=jd>Sport</a> · <a href=ja>Météo</a> · <a href=ma>Cartes</a> <b>Loisirs :</b> <a href=jx><b>Jeux</b></a> · <a HREF=bh>Logithèque</a> · <a HREF=mu>Musique</a> · <a HREF=ep>Encyclopédie</a> · <a href=bg><b>Astrologie</b></a> · <a href=au>Auto</a><br><b>Communication :</b> <a href=be>Courrier</a> · <a href=ab>Carnet d’adresses</a> · <a href=cv>Cartes de voeux</a> · <a href=bj>Messenger</a> · <a href=gr><b>Groupes</b></a> · <a href=tc>Tchatche</a> · <a href=yp>Annuaire Pro</a> · <a href=mo>Mobile</a><br><b>Achats :</b> <a href=bk>Shopping</a> · <a href=tx><b>Voyages</b></a> · <a href=en>Enchères</a> · <a href=jc>Annonces</a> <b>Perso :</b> <a href=bi><b>Mon Yahoo!</b></a> · <a href=cp>Compagnon</a> · <a href=ag>Agenda</a> · <a href=ph>Photos</a> -- <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 !</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é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> <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> <a href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/>Yahoo! Voyages</a> : <a href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/loc/>Offres sports d’hiver</a> <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> · <a href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/flights/>Billets d’avion</a> <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> · <a href=http://fr.yahoo.com/home/travel/*http://fr.travel.yahoo.com/affaires/>Bonnes affaires</a> <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 :</b> <a href=bc>Actualités</a> · <a href=bf><b>Finance</b></a> · <a href=jd>Sport</a> · <a href=ja>Météo</a> · <a href=ma>Cartes</a> <b>Loisirs :</b> <a href=jx><b>Jeux</b></a> · <a HREF=bh>Logithèque</a> · <a HREF=mu>Musique</a> · <a HREF=ep>Encyclopédie</a> · <a href=bg><b>Astrologie</b></a> · <a href=au>Auto</a><br><b>Communication :</b> <a href=be>Courrier</a> · <a href=ab>Carnet d’adresses</a> · <a href=cv>Cartes de voeux</a> · <a href=bj>Messenger</a> · <a href=gr><b>Groupes</b></a> · <a href=tc>Tchatche</a> · <a href=yp>Annuaire Pro</a> · <a href=mo>Mobile</a><br><b>Achats :</b> <a href=bk>Shopping</a> · <a href=tx><b>Voyages</b></a> · <a href=en>Enchères</a> · <a href=jc>Annonces</a> <b>Perso :</b> <a href=bi><b>Mon Yahoo!</b></a> · <a href=cp>Compagnon</a> · <a href=ag>Agenda</a> · <a href=ph>Photos</a> -- <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> <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 !</small></font></td></tr> <tr><td> </td><td> <small><b>Cotations</b><br> · <a href="http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/q?s=@350000.PA&f=snlcvi">CAC 40</a><br> · <a href="http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/q?s=@SRD_AB.PA&f=snlcvi">SRD</a><br> · <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> · <a href="http://fr.yahoo.com/home/bf/*http://fr.finance.yahoo.com/a43?u">Palmarès</a></small></td> <td> </td><td> <small><b>Actualités/Analyses</b><br> · <a href="http://fr.yahoo.com/home/bf/*http://fr.biz.yahoo.com/paris.html">Séance du jour</a><br> · <a href="http://fr.yahoo.com/home/bf/*http://fr.biz.yahoo.com/actualite/analyse/">Recommandations</a><br> · <a href="http://fr.yahoo.com/home/bf/*http://fr.biz.yahoo.com/screen/">Indices sectoriels</a><br> · <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>[ <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> ] </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 : <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>À la une</b></font></td></tr><tr><td><table width=100% cellpadding=0 cellspacing=0 border=0> <tr><td valign=top> <b>·</b> </td><td><small><a href=http://fr.yahoo.com/home/etranger/*http://fr.fc.yahoo.com/p/proche-orient.html>Gaza : le fondateur du Hamas assigné à résidence</a> </small></td></tr><tr><td valign=top> <b>·</b> </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é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> <b>·</b> </td><td><small><a href=http://fr.yahoo.com/home/france/*http://fr.news.yahoo.com/politique/>Intervention télévisée de L. Jospin, « probable » candidat</a></small></td></tr><tr><td valign=top> <b>·</b> </td><td><small><a href=http://fr.yahoo.com/home/france/*http://fr.fc.yahoo.com/d/dossiercorse.html>Paillotes : prison ferme requise contre Bernard Bonnet</a> </small></td></tr><tr><td valign=top> <b>·</b> </td><td><small><a href=http://fr.yahoo.com/home/culture/*http://fr.movies.yahoo.com/films/filmsdelasemaine.html>Cinéma : les films de la semaine</a></small></td></tr><tr><td valign=top> <b>·</b> </td><td><small><a href=http://fr.yahoo.com/home/sport/*http://fr.sports.yahoo.com/>Sport</a> : <a href=http://fr.yahoo.com/home/sport/*http://fr.sports.yahoo.com/tennis/>Tennis</a> · <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> <b>·</b> </td><td><small>Non, vous n'êtes pas seul... <a href=http://fr.yahoo.com/home/comm/?http://fr.docs.yahoo.com/comm/>Voici les communautés Yahoo!</a></small></td></tr> </table></td></tr><tr><td align=center bgcolor=#e0d0b0><font face=arial size=2><b>Et sur Yahoo!</b></font></td></tr><tr><td><table cellpadding=0 cellspacing=0 border=0 width=100%> <tr><td valign=top> <b>·</b> </td><td><small><a href=http://fr.yahoo.com/home/ency/*http://fr.encyclopedia.yahoo.com>Y! Encyclopédie</a> : <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>États du monde</a></small></td></tr><tr><td valign=top> <b>·</b> </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é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> <b>·</b> </td><td><small><a href=http://fr.yahoo.com/home/selection/*http://fr.docs.yahoo.com/selection/>Les sites sélectionnés cette semaine par Yahoo!</a></small></td></tr><tr><td valign=top> <b>·</b> </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 :</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 :</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 :</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 :</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 :</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 :</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 :</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 :</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! :</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/
Comment 2•23 years ago
|
||
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
Reporter | ||
Comment 3•23 years ago
|
||
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)
Comment 4•23 years ago
|
||
Reporter, create a new profile 'mozilla -profilemanager' and see if it fixes the problem.
Reporter | ||
Comment 5•23 years ago
|
||
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....
Comment 6•23 years ago
|
||
Marking WORKSFORME as per reporter comments.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 7•23 years ago
|
||
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?
Comment 8•23 years ago
|
||
reopening.
Status: RESOLVED → UNCONFIRMED
Component: Browser-General → Networking: Cache
Resolution: WORKSFORME → ---
Comment 10•22 years ago
|
||
i cant seem to produce this problem with moz 0.9.8 (2002020406) on win2k, could anyone else try with newer build
Comment 11•22 years ago
|
||
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.
Comment 12•22 years ago
|
||
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 ?
Comment 13•22 years ago
|
||
another site where i see this is http://www.hirschmann.de/product_tree.php3?mode=show&id=1170
Comment 14•22 years ago
|
||
Comment 15•22 years ago
|
||
Comment 16•22 years ago
|
||
attached 2 screenshots, keep an eye on the scrollbars ... happens with latest nightly, totally clean install and new profile.
Comment 17•22 years ago
|
||
*** Bug 131555 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
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
Comment 19•22 years ago
|
||
all pages WFM now with 2002040403 !!!!
Comment 20•22 years ago
|
||
WFM, too (2002042510, Win2k) William, do you still see this bug?
Reporter | ||
Comment 21•22 years ago
|
||
This bug still reproducible for me on NT using Mozilla RC1 for windows.
Comment 22•22 years ago
|
||
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
Comment 23•22 years ago
|
||
still WFM with RC3
Comment 24•22 years ago
|
||
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 ago → 22 years ago
Resolution: --- → WORKSFORME
Comment 25•22 years ago
|
||
its back, and its even happening on this page 2002120308 trunk win2k
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Comment 26•22 years ago
|
||
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...
Comment 27•22 years ago
|
||
- 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
Comment 28•22 years ago
|
||
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
Comment 29•22 years ago
|
||
*** Bug 138419 has been marked as a duplicate of this bug. ***
Comment 30•22 years ago
|
||
*** Bug 187676 has been marked as a duplicate of this bug. ***
Comment 31•22 years ago
|
||
*** Bug 130675 has been marked as a duplicate of this bug. ***
Comment 32•22 years ago
|
||
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.
Comment 33•22 years ago
|
||
over to intl to investigate the encoding issue.
Assignee: gordon → smontagu
Component: Networking: Cache → Internationalization
Keywords: qawanted
QA Contact: tever → ylong
Comment 34•22 years ago
|
||
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.
Comment 35•22 years ago
|
||
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).
Comment 36•22 years ago
|
||
That should be comment 18, not 118. And sorry for the spam.
Comment 37•22 years ago
|
||
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).
Comment 38•22 years ago
|
||
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.
Comment 39•22 years ago
|
||
This is taken from http://www.2of3.com/mozilla/bug01.html by Joe Amersdorfer (linked from dupe bug 138419)
Comment 40•22 years ago
|
||
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.
Comment 42•22 years ago
|
||
*** Bug 149561 has been marked as a duplicate of this bug. ***
Comment 43•22 years ago
|
||
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
Comment 44•21 years ago
|
||
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.
Comment 45•21 years ago
|
||
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.
Comment 46•21 years ago
|
||
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?
Comment 47•21 years ago
|
||
Mozilla 1.3b Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Comment 48•21 years ago
|
||
bug 189628 related ???
Comment 49•21 years ago
|
||
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.
Comment 50•21 years ago
|
||
does this only happen to lines w/ umlauts characters (ä ö ü)?
Comment 51•21 years ago
|
||
*** Bug 189628 has been marked as a duplicate of this bug. ***
Comment 52•21 years ago
|
||
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.
Comment 53•21 years ago
|
||
*** Bug 194293 has been marked as a duplicate of this bug. ***
*** Bug 194254 has been marked as a duplicate of this bug. ***
Comment 55•21 years ago
|
||
Here's another web page that shows this behaviour: http://pregnancy.about.com/library/blbabynames.htm
Comment 56•21 years ago
|
||
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 (­ = 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. "ü") or the unicode version (i.e. "ü"); 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?
Comment 57•21 years ago
|
||
Updated•21 years ago
|
Attachment #126410 -
Attachment description: Unicode testcase using JavaScript → Testcase for detecting affected characters
Comment 58•21 years ago
|
||
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.
Comment 59•21 years ago
|
||
Comment 60•21 years ago
|
||
Comment 61•21 years ago
|
||
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?
Comment 62•21 years ago
|
||
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
Comment 63•21 years ago
|
||
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.
Comment 64•21 years ago
|
||
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.
Comment 65•21 years ago
|
||
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
Comment 66•21 years ago
|
||
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.)
Comment 67•21 years ago
|
||
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!)
Comment 68•21 years ago
|
||
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!
Comment 69•21 years ago
|
||
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
Comment 70•21 years ago
|
||
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...
Comment 71•21 years ago
|
||
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?
Comment 72•21 years ago
|
||
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.
Comment 73•21 years ago
|
||
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).
Assignee | ||
Comment 74•21 years ago
|
||
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?!?
Comment 75•21 years ago
|
||
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.
Comment 76•21 years ago
|
||
Ah, that should be instructions and not introductions.
Assignee | ||
Comment 77•21 years ago
|
||
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
Assignee | ||
Comment 78•21 years ago
|
||
"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.
Assignee | ||
Comment 79•21 years ago
|
||
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)
Assignee | ||
Comment 80•21 years ago
|
||
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)
Assignee | ||
Comment 81•21 years ago
|
||
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)
Assignee | ||
Comment 82•21 years ago
|
||
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+
Assignee | ||
Comment 84•21 years ago
|
||
Checked in. Marking FIXED, but some day if time permits, I might dig the nsTextFrame side of ths story.
Assignee: roc+moz → rbs
Assignee | ||
Comment 85•21 years ago
|
||
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?
Assignee | ||
Comment 86•21 years ago
|
||
fixed-on-trunk
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
Comment 87•21 years ago
|
||
rbs: Is there a bug# for the nsTextFrame thing?
Comment 88•21 years ago
|
||
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.
Assignee | ||
Comment 89•21 years ago
|
||
*** Bug 184714 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 90•21 years ago
|
||
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.
Comment 91•21 years ago
|
||
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 92•21 years ago
|
||
Comment on attachment 126723 [details] [diff] [review] better and more readable patch moving approval request forward.
Attachment #126723 -
Flags: approval1.4? → approval1.4.x?
Comment 93•21 years ago
|
||
*** Bug 179544 has been marked as a duplicate of this bug. ***
Comment 94•21 years ago
|
||
*** Bug 207821 has been marked as a duplicate of this bug. ***
Comment 95•21 years ago
|
||
*** Bug 205345 has been marked as a duplicate of this bug. ***
Comment 96•21 years ago
|
||
*** Bug 212386 has been marked as a duplicate of this bug. ***
Comment 97•21 years ago
|
||
*** Bug 211558 has been marked as a duplicate of this bug. ***
Comment 98•21 years ago
|
||
*** Bug 157703 has been marked as a duplicate of this bug. ***
*** Bug 214739 has been marked as a duplicate of this bug. ***
Comment 100•21 years ago
|
||
*** 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+
Comment 103•21 years ago
|
||
*** Bug 171054 has been marked as a duplicate of this bug. ***
*** Bug 155689 has been marked as a duplicate of this bug. ***
Comment 105•20 years ago
|
||
*** Bug 211840 has been marked as a duplicate of this bug. ***
Comment 106•20 years ago
|
||
I have found this bug once again in Mozilla Firefox, version 0.9.2
Assignee | ||
Comment 107•20 years ago
|
||
Steps to reproduce? You have to be more careful when awaking old demons like that.
Comment 108•20 years ago
|
||
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.
Assignee | ||
Comment 109•20 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•