Jag skulle häromdagen skapa en cookie i .NET WebBrowser-kontrollen via WebBrowser.Document.Cookies och gjorde så här (min WebBrowser-instans heter ”browser” i exemplen nedan):

browser.Document.Cookies = "MyCookie=My value";

Den (interna) webbapplikation som browsern navigerade runt i kunde sedan verifiera att cookien fanns och göra vissa saker baserat på det, följt av att sätta cookien till ett annat värde. Det var bara det att ibland verkade cookien ha flera olika värden under samma request, vilket orsakade ett oönskat beteende. När jag tittade närmare på det insåg jag att det ibland fanns dubbletter av cookien. Vadan?

Jag började med att ägna en eftermiddag åt att testa olika varianter av ”kolla-om-cookien-finns-i-så-fall-sätt-den-till-ditten-annars-sätt-den-till-datten-eller-ta-bort-den” och andra dumheter tills det var dags att gå hem för dagen med bultande huvudvärk och dåligt humör.

Nästa dag inledde jag istället med att googla efter typ ”duplicate cookies” och hittade ett kort blogginlägg med budskapet:

Kom ihåg att alltid sätta path för dina cookies, annars defaultar den till den aktuella sidans URL vilket kan leda till dubbletter.

Inlägget handlade visserligen om att sätta cookies genom Javascript och document.cookies, men det är mer eller mindre precis samma sak som att göra det via WebBrowser.Document.Cookies. Så hur sätter man path för en cookie? En ny googling tog mig till en beskrivning av cookies på Quirksmode.org och insikten:

browser.Document.Cookies = "MyCookie=My value; path=/";

Genom det enkla tillägget började min cookie gälla för hela sajten och alla dubbletter försvann hux flux.

Slutsats: Sätt alltid path för dina cookies och ta en paus med lite frisk luft och kanske ett mellanmål när du försöker lösa ett problem men är för trött för att inse att Google har svaret…

Hursomhelst – eftersom sidan har mycket Javascript kopplade till rader i sökresultat och liknande så är den lite av ett lidande för de flesta webbläsare att rendera (särskilt IE6). På kul testade jag att göra vår senaste storhandling i Google Chrome istället för Firefox, och det var en ruskig skillnad! Istället för frustration gick allt faktiskt smidigt. Nästan så att jag glömde bort hur dumt de implementerat sin lösning…

Ett mycket hett tips till alla som använder Mataffären.se alltså.

Som jag ser det är problematiken indelad i ett par olika delar med olika klurighetsgrader. Först och främst måste jag komma på hur jag gör ett titthål (hädanefter kallad ”viewport”) som man kan titta på en yta genom och som stödjer panorering med muspekaren. Detta visade sig vara helt okej enkelt. Grundprincipen är att lägga den stora ytan som man vill panorera över inuti ett element med CSS-attributet overflow: hidden (bland annat). Det betyder att även om ytan är jättestor så syns bara en så stor del som får plats i det yttre elementet. För att kunna panorera krävs även att det yttre elementet, viewporten, har position: relative och att det inre, canvasen, har position: absolute. Sedan kan man använda Javascript för att manipulera canvasens position relativt viewportens. Ganska rättframt.

De mer utmanande tankenötterna börjar rada upp sig när det kommer till att dynamiskt läsa in och visa upp tiles. En webbläsare fungerar så att den börjar ladda in en bildfil så snart som den får veta dess sökväg, exempelvis genom ett src-attribut på en img-tagg eller som värde på ett elements background-image-styleattribut. Detta innebär att bara vi vet URL:en till en given tile så tar webbläsaren hand om den ”streaming” som behövs för att visa upp bilden. Mycket bekvämt.

Låt säga att vi har ett enkelt koordinatsystem där varje tile har unika koordinater. För enkelhetens skull (och det finns ju ingen anledning att inte hålla det enkelt) bestämmer jag att en tile exempelvis kan ha koordinaterna (0, 0). Motsvarande bildfil heter troligen 0-0.jpg och ligger i mappen Images/Tiles. Eftersom strukturen är känd kan klienten själv lista ut URL:en till varje tile, och samtidigt beräkna vilken position den ska ha relativt canvasen. Men hur ska den veta vilka tiles som ska vara synliga vid ett givet tillfälle?

Klienten vet hur stor viewporten är, och kan därför veta hur många tiles den motsvarar. Man skulle kunna tänka sig att först ta reda på vilken tile som är ”i mitten” av viewporten och sedan ladda in ett visst antal tiles relativt denna i både X och Y-led. När användaren sedan panorerar över canvasen så ändras den mittersta tilen, vilket ger en ny bas för beräkning av vilka tiles som ska vara synliga.

Gamla tiles, sådana som inte syns längre, tas bort från dokumentträdet för att det inte ska bli för stort och klumpigt. Eftersom webbläsaren i normalfallet cachar de bilder den laddar in kommer det ändå gå mycket snabbt att visa upp tiles som tidigare tagits bort om användaren skulle panorera tillbaka.

Det finns klara begränsningar som styr vad man kan göra samtidigt som en smidig resonsivitet i GUI:t bibehålls (kom ihåg att användaren kanske panorerar omkring helt godtyckligt, då duger det inte med en massa fördröjningar och lagg). Ett s¥dant exempel är att det faktiskt tar tid att skapa noder i DOM-trädet (vilket är vad man gör när man lägger till en tile). Ju mindre tiles, desto fler ska synas samtidigt vilket betyder fler aktiva noder för varje givet tillfälle. Responsiviteten minskar. Det hela blir en avvägning – vilken är den bästa tilestorleken i förhållande till prestanda och syfte? Detta är bara en av de frågor som jag stött på under mitt experimenterande hittills.

Den approach till problemet som jag skrivit helt kort om här är såklart bara en variant, kanske läroböcker i dynamiska webbapplikationer (finns det sådana?) skulle kalla den naiv. Men det är klart att jag inte kan skriva om alla finesser och knep nu direkt, då blir det ju inget roligt! Detta är ett löpande hobbyprojekt som jag har tänkt lägga en hel del tid på. Jag kommer säkert att skriva mer om olika detaljer framöver. Till sist har jag förhoppningsvis ett schysst resultat att visa, med en grundlig teknisk ”bakom kulisserna”-genomgång som bonus.

Då och då kommer jag (kanske) göra releaser av det jag åstadkommit hittills, och den senaste versionen hittar du alltid på http://koncept.fjeldstad.se. Tycker du att den ser konstig ut så beror det med stor sannolikhet på att den gör det.

Webbapplikationen tycks gå långsammare när browsern varit igång länge. Finns det en minnesläcka på klientsidan? Undersök!

Jag ligger bra till tidsmässigt just nu i projektet så jag hade möjlighet att titta närmare på frågan. Det visade sig att minnesläckor i webbläsaren i samband med vissa Javascript/DOM-kopplingar är välkända, och diskuteras bland annat på den här bloggen, i denna CodeProject-artikel och hos Microsoft.

Ett problem tycks vara eventhanterare, och att man alltid bör ”koppla bort” dem då sidan avslutas (vid window-objektets unload-event). Spontant känner jag att detta automatiskt borde hanteras av den funktionalitet som från början kopplar upp eventhanterarna, exempelvis $addHandler om man använder AJAX Library. Kanske är det redan så? Jag tror dock inte det. Jag ska gräva lite djupare i det hela, blir väl till slut kanske tvungen att implementera något i stil med denna lösning för eventhantering.

Sedan får man inte glömma bort alla andra mönster som kan framkalla de här minnesläckorna (som beskrivs mer noggrannt i ovan nämnda artiklar). Ibland, när det känns som att jag tvingas lägga tid på olika hack för att komma runt begränsningar i webbläsaren, önskar jag att hela termen ”webbapplikation” aldrig uppstått…tacka vet jag hederliga hemsidor!