
A hírhedt 10.5.6-os frissítés telepítése óta küzdöttem egy buggal. Sokáig egyáltalán nem volt egyértelmű, hogy a bugot a Safari okozza, így aztán eltartott egy darabig mire sikerült megoldást találnom a hibára.
Egy webes feladatnyilvántartó (GTD)/számlázó szolgáltatás fejlesztésén dolgozok. A szolgáltatás saját hitelesítést használ és bejelentkezéskor megadható, hogy következő látogatáskor automatikusan léptessen be a rendszer. Ekkor az alkalmazás – jól megszokott módon – a böngészőben, egy cookie-ban tárolja el a felhasználót és a hitelesítési jegyet. A szolgáltatás ezen része már hónapokkal korábban elkészült, sőt belső körökben már egy ideje a tesztelés folyik. Így meglepetésként ért, amikor nagyon ronda – a hitelesítés modullal összefüggésben lévő – hibák kezdtek megjelenni lépten-nyomon.
Az alkalmazást Fluiddal használom és pont a hiba megjelenése előtt jött ki egy Fluid frissítés. Így első körben teljesen triviálisnak tűnt, hogy a fluid okozza a hibát. Rápróbáltam Safarival is, de a hiba itt is ugyanúgy jelentkezett (tudom, tudom same engine). Később valamiért elterelődött a gyanú a böngészőről és a kódban kezdtem el debuggolni, nem túl sok sikerrel. Végül ismét a Webkit-re kezdtem fókuszálni, miután feltűnt, hogy más webes cuccok cookie-jai is eltünedeznek, míg Firefoxszal hibátlanul működik minden. Az Apple fórumán találtam hasonló – cookie elveszéses – hibákról szóló topikokat. Másoknál is jelentkezett ez a bug a 10.5.6-os OS X frissítést követően és többen javasolták a böngésző újratelepítését.
Le is rántottam a Safari (3.2.1) image-et az Apple-től. Feltelepítettem a programot, majd újraindítottam. Azóta kifogástalanul menti a Fluid is és a Safari is a cookie-kat és a szolgáltatás hitelesítésével sincs gond. Süti!
Az IE6-nak még mindig meglehetősen nagy felhasználói tábora van. Erre a hallomáson túl abból is következtetek, hogy az általam hozzáférhető site-ok statisztikáit böngészve még mindig jelentős számú 6-os verziójú Internet Explorer tűnik fel. Bár közismert, hogy mennyire bugos ez a böngésző, – a felhasználói táborára való tekintettel – továbbra sem szabad megfeledkezni az IE6-al történő tesztelésről. Meglehetősen gusztustalan hibák és oldalszéthullások tudnak ilyenkor előjönni, melyeket illik mielőbb javítani.
Az egyik “kedvenc” bugom hogy a div-re illesztett
stílussal nem képes megbirkózni és ahelyett, hogy az érintett div-et középre igazítaná, mozdulatlanul hagyja. A <center> tag ugyebár nem szabványos és legjobb tudomásom szerint nem illik használni így nemrég valami szabványos css hack után kezdtem kutakodni (tapasztaltabb designerektől, webprogramozóktól elnézést kérek). Találtam is egy szép megoldást ami nem gyengén lepett meg. Valahol azt írták, hogy az érintett div-nek adjunk egy
attribútumot. Megmondom őszintén kicsit furának találtam és nem igazán hittem benne, hogy működni fog, de bejött. Tehát
text-align: center;
margin: 1em auto;
és az általam tesztelt böngészőkkel (IE6, IE7, Firefox, Camino, Safari 2, Safari 3 Beta) a kívánt célt sikerült elérni.
A böngészőtesztek elvégzésére egyébként két nagyon hasznos oldalt tudok ajánlani:
- IE NetRenderer: kifejezetten Internet Exploreres renderelést tesz lehetővé. Az on-line renderelt képet azonnal megjeleníti. IE7, IE6, IE5.5 valamint IE7-IE6 Mixed és Difference szolgáltatásokat nyújt. Ez utóbbi két funkció külön érdekessé teszi a szolgáltatást.
- BrowserShots: Az összes ismertebb böngésző, különböző operációs rendszereken történő renderelését teszi lehetővé. Az eredmény sokkal lassabban érkezik mint ez IE NetRenderer esetén – saját tapasztalatom alapján akár fél óra is lehet -, ami teljesen helyénvaló hiszen sokkal több munkát végez. Plusz pont továbbá, hogy az végeredményeket egy zip fájlban is elérhetővé teszik letöltésre.
Egy kedves olvasó felhívta a figyelmemet egy hibára, amit javítottam is. A hiba ebben a kódrészben volt, a /postfix-x.x.x/src/virtual/maildir.c állományban:
if (((tqf = fopen(tmpquotafile, "w")) != NULL) && (send_quotawarn)) {
if ((infile = fopen("/etc/quotawarnmsg", "r")) != NULL) {
...
fclose(tqf);
}
unlink(tmpquotafile);
}
Márpedig ha a /etc/quotawarnmsg-t nem sikerül megnyitni olvasásra, akkor a második feltétel nem teljesül és a fájl lezárása nem történik meg.
A javítás csupán annyiból áll, hogy az fclose(tqf);-et a második feltétel után, az unlink(tmpquotafile); előtti sorba kell áthelyezni:
if (((tqf = fopen(tmpquotafile, "w")) != NULL) && (send_quotawarn)) {
if ((infile = fopen("/etc/quotawarnmsg", "r")) != NULL) {
...
}
fclose(tqf);
unlink(tmpquotafile);
}
Letöltés
Legyen mondjuk 0.0.2-es softquota verziószámú: