[IE6] is er een fix voor de kleine-plaatjes bug?

dinsdag 7 oktober 2003 13:26

Devver

Pixelated

Hoe laad je die plaatjes in? Creeer je die met javascript dmv new Image(), of schrijf je image-tags weg mbv innerHTML?
Zelf laat ik in DHTML apps ook veel plaatjes, maar ik heb nog nooit last gehad van deze bug...

Intentionally left blank

Acties:

dinsdag 7 oktober 2003 13:35

Topicstarter

in eerste instantie document.createElement("img"), later new Image() en nu laad ik ze gewoon onderaan in de body met een onzichtbare style. dit om te kijken of het op die manier op te lossen was. het leek erop dat de methoden respectievelijk steeds beter waren, maar misschien is dat gewoon toeval.

[ Voor 3% gewijzigd door Genoil op 07-10-2003 13:26 ]

Acties:

dinsdag 7 oktober 2003 13:40

Devver

Pixelated

ik sla preloaded plaatjes altijd op in een global array, bij het creeeren van een image-element verwijs ik vervolgens naar het preloaded element:

JavaScript:

var preload = [];
preload[0] = new Image();
preload[0].src = 'plaatje.gif';

var newImg = document.createElement('img');
newImg.src = preload[0].src;
document.body.appendChild(newImg);

hier zet ik uiteraard nog code omheen om te bepalen of alle images geladen zijn voordat ik ze toevoeg aan de pagina, maar in ieder geval heb ik nog nooit problemen gehad met plaatjes die niet wilden laden...

Intentionally left blank

Acties:

Verwijderd

Welkom bij de club gedupeerde ([rml][ bug] iemand al meegemaakt en workaround bedacht?[/rml]).

Ik heb er nooit een oplossing voor kunnen vinden, het is een bug in de implementatie van innerHTML en afgeleiden daarvan waaronder insertAdjacentHTML.

Zodra je innerHTML zullen evt. afbeeldingen ook niet uit je cache worden gehaald, maar weer vanaf de server wordt opgeroepen.

Ik ben momenteel zelf bezig met een treeview, en heb momenteel even gekozen voor een document.createElement oplossing ipv innerHTML, en ga vanzelf wel zien of dit soepel werkt.

Meer informatie (ik ben er wekenlang mee bezig geweest):
http://support.microsoft....aspx?scid=kb;en-us;269802
http://support.microsoft....aspx?scid=kb;EN-US;183110

Dit probleem treedt ook op in Mozilla, Opera, etc. etc. er wordt gewoon een soort van Dos Attack uitgevoerd op de wininet.dll. Niets aan te doen helaas. Het treed ook op bij xml->xslt transformaties via javascript, hetzijn in mindere matwe.

[ Voor 5% gewijzigd door Verwijderd op 07-10-2003 13:42 ]

dinsdag 7 oktober 2003 13:44

Acties:

André

Analytics dude

Dus conclusie: weg met de ranzige innerHTML en welkom DOM-methode.

dinsdag 7 oktober 2003 14:04

Acties:

dinsdag 14 oktober 2003 13:03

Topicstarter

dank jullie wel! ik (euhm eigenlijk m'n collega

) gaat er verder mee stoeien. als er nog baanbrekende ontdekkingen komen laat ik het wel weten!

Acties:

dinsdag 14 oktober 2003 20:27

Topicstarter

Het probleem is uiteindelijk verholpen door de Image.complete property te gebruiken. Voordat de plaatjes worden toegevoegd aan het document worden ze eerst gepreload en op gechecked of ze binnen zijn.

Acties:

Verwijderd

Genoil schreef op 14 October 2003 @ 13:03:
Het probleem is uiteindelijk verholpen door de Image.complete property te gebruiken. Voordat de plaatjes worden toegevoegd aan het document worden ze eerst gepreload en op gechecked of ze binnen zijn.

Mag ik je uitnodigen om je cache settings eens op "every visit... " te zetten

Geheid dat die alsnog gaat hangen.

Ik was met een treeview component begonnen, en loop gewoon weer tegen het probleem aan. Zelfs zonder innerHTML

Je kunt het probleem perfect zien, als je de volgende pagina (ben ik momenteel mee bezig) opent. Als je cache settings op "automatically" staat, gaat alles perfect.

Zet je de cache settings op "every visit..." dan hangt je browser.

http://members.chello.nl/m.schopman1/tree/treeview.html

En dan op de homepage node klikken, en dan op de load link die de childNodes dan gaat laden uit een xml bestand.

[ Voor 29% gewijzigd door Verwijderd op 14-10-2003 20:29 ]

dinsdag 14 oktober 2003 21:45

Acties:

MAZZA

Barbie is er weer!

Werkt hier gewoon met beide cache settings

dinsdag 14 oktober 2003 21:46

Acties:

Verwijderd

MAZZA schreef op 14 October 2003 @ 21:45:
Werkt hier gewoon met beide cache settings

Doe maar is een paar keer de pagina herladen en nogmaals een load doen op de homepage node. Binnen een paar tellen zul je zien, IE hangt..

Mozilla gaat hier uiteraard wel goed mee om.

Ik ben nu de hele boel aan het omgooien want ook de append method icm het zetten van style.backgroundImage zorgde voor een leuke dos attack op de browser.

Ik haal nu al 50 nodes in no time binnen

[ Voor 5% gewijzigd door Verwijderd op 14-10-2003 21:48 ]

dinsdag 14 oktober 2003 21:56

Acties:

MAZZA

Barbie is er weer!

Verwijderd schreef op 14 October 2003 @ 21:46:
[...]

Doe maar is een paar keer de pagina herladen en nogmaals een load doen op de homepage node. Binnen een paar tellen zul je zien, IE hangt..

Ik krijg het echt niet voor elkaar

IE 6.0.2800.1106 onder XP

dinsdag 14 oktober 2003 21:58

Acties:

Verwijderd

Ik heb oa Clay het laten uitproberen, college's, en mijn baas, overal hing het ... zoals verwacht. Heb je je cache settings wel op "every visit to the page" staan? anders hangt die idd niet.

IE gaat dan voor elke node de kruisingen, backgrounds, en icons opnieuw opvragen. Hij doet dat lekker handig in luttele milliseconden, en deze komen terecht in wininet.dll

Die staat gelimiteerd in je registry op zoveel requests per keer, en IE gaat daar dan overheen. Op dat moment hangt de boel.

[ Voor 46% gewijzigd door Verwijderd op 14-10-2003 22:00 ]

dinsdag 14 oktober 2003 22:10

Acties:

MAZZA

Barbie is er weer!

Zo heb ik dat gedaan ja. Internet options, Temporary internet files, settings en dan op "every visit to the page"

Beats me

/edit: Ben wel stevig aan het downen. Misschien dat de plaatjes daardoor te langzaam binnen komen.

[ Voor 32% gewijzigd door MAZZA op 14-10-2003 22:11 ]

dinsdag 14 oktober 2003 22:18

Acties:

dinsdag 14 oktober 2003 22:37

Bij mij crasht IE ook niet (cache settings ook aangepast, meerdere loads en refreshes).

Ver: IE6.0.2800.1106.xpsp2(etc)

Hij crasht alleen als ik op load klik (vanuit de hompepage node) terwijl de homepage node al is geladen.

To study and not think is a waste. To think and not study is dangerous.

Acties:

Verwijderd

wazig

.. naja.. dit was toch pas een eerste versie.... met *kuch* achteraf gezien bijzonder slecht gebruik van een bepaalde background image

Moet zowiezo op de remove method nog behoorlijk wat werk verrichten om de objects en de referenties te verwijderen, dat wordt nog een hel opzich.

woensdag 15 oktober 2003 10:50

Acties:

woensdag 15 oktober 2003 15:24

Topicstarter

Verwijderd schreef op 14 October 2003 @ 20:27:
[...]

Mag ik je uitnodigen om je cache settings eens op "every visit... " te zetten Geheid dat die alsnog gaat hangen.

Daar staat m'n browser standaard op ingesteld en het is echt geen probleem. Be my guest:

http://www.shapers.nl/new (under construction)

Ik weet niet precies hoe m'n collega het heeft gefixed, maar dat kun je uiteraard zelf opzoeken

Acties:

Verwijderd

Genoil schreef op 15 October 2003 @ 10:50:
[...]

Daar staat m'n browser standaard op ingesteld en het is echt geen probleem. Be my guest:

http://www.shapers.nl/new (under construction)

Ik weet niet precies hoe m'n collega het heeft gefixed, maar dat kun je uiteraard zelf opzoeken

Een treeview met +100 afbeeldingen is wel wat anders dan een average website met afbeeldingen die niet via javascript worden toegevoegd. Dit is appels met peren vergelijken

woensdag 15 oktober 2003 15:26

Acties:

Godjira

To infinity and beyond!

Heb je op die IE6 wel de SP1 al geinstalleerd?

Profile

woensdag 15 oktober 2003 17:45

Acties:

donderdag 16 oktober 2003 08:36

Topicstarter

Verwijderd schreef op 15 October 2003 @ 15:24:
[...]

Een treeview met +100 afbeeldingen is wel wat anders dan een average website met afbeeldingen die niet via javascript worden toegevoegd. Dit is appels met peren vergelijken

Euhm die isometrische plaat op de index bestaat uit plm. 50 afbeeldingen, nogeens 50 worden er dynamisch bij geladen als ze nodig zijn. Ongeveer 50 van alle plaatjes zijn zo'n 150 bytes groot. Lijkt mij genoeg om met een average treeview te vergelijken

Alleen op MacIE hebben we van de uitdaging afgezien en ik meen dat ie het op Apple Safari (nog) niet doet.

[ Voor 11% gewijzigd door Genoil op 15-10-2003 18:02 ]

Acties:

Verwijderd

Genoil schreef op 15 October 2003 @ 17:45:
[...]

Euhm die isometrische plaat op de index bestaat uit plm. 50 afbeeldingen, nogeens 50 worden er dynamisch bij geladen als ze nodig zijn. Ongeveer 50 van alle plaatjes zijn zo'n 150 bytes groot. Lijkt mij genoeg om met een average treeview te vergelijken

Alleen op MacIE hebben we van de uitdaging afgezien en ik meen dat ie het op Apple Safari (nog) niet doet.

50 valt op zich mee, maar ik heb ooit eens een treeview gebruikt, daar zat je heel makkelijk op 250+ afbeeldingen

[ Voor 12% gewijzigd door Verwijderd op 16-10-2003 08:37 ]

donderdag 16 oktober 2003 10:51

Acties:

woensdag 29 oktober 2003 16:48

Topicstarter

Verwijderd schreef op 16 October 2003 @ 08:36:
[...]

50 valt op zich mee, maar ik heb ooit eens een treeview gebruikt, daar zat je heel makkelijk op 250+ afbeeldingen

Wat maakt het aantal plaatjes nou uit? Het probleem zit em toch in de snelheid waarmee kleine plaatjes dynamisch ingeladen worden? Dan kan 2 misschien zelf wel genoeg zijn. Ik snap overigens totaal niet wat er nou zo relevant is aan een tree met 250 plaatjes. Ik neem aan dat je daarmee het totale aantal bedoelt, niet unieke plaatjes? Een tree met 1 icontype heeft zo'n 10 plaatjes. Als die 1 keer goed zijn ingeladen, gaan de overige 240 copieen ook wel goed denk ik. Of is dat juist het probleem?

Acties:

Verwijderd

Ik wilde dit topic toch even omhoog gooien, aangezien ik een perfecte test case heb om te laten zien wat er gebeurt.

Ik heb dus de afgelopen tijd een crossbrowser dhtml treeview component gemaakt en heb een klein gedeelte hiervan live getest. Et voila, MSIE crashed, en Mozilla gaat echt perfect.

Zet je cache settings op every visit to the page, en wacht eventjes. Er zit een document.location.reload op de pagina, en een body onload die een method van de treeview aanroept.

http://members.chello.nl/.../treewidget/treeview.html

[ Voor 4% gewijzigd door Verwijderd op 29-10-2003 16:49 ]

woensdag 29 oktober 2003 17:00

Acties:

woensdag 29 oktober 2003 17:19

Na hoeveel keer moet je browser crashen? Bij mij crasht IE niet namelijk, maar na zo'n 150 keer auto-reload gaat ie niet verder en laat ie een lege pagina zien. Ik kan vervolgens nog wel andere pagina's bezoeken, maar jouw site blijft blanko tenzij ik een nieuwe IE-sessie start. Maar ja, als ik hem nu terug zet op zijn normale cache setting en IE opnieuw start, laat ie al na 2 of 3 keer niets meer zien (nog steeds geen crash trouwens).

To study and not think is a waste. To think and not study is dangerous.

Acties:

Verwijderd

slm schreef op 29 oktober 2003 @ 17:00:
Na hoeveel keer moet je browser crashen? Bij mij crasht IE niet namelijk, maar na zo'n 150 keer auto-reload gaat ie niet verder en laat ie een lege pagina zien. Ik kan vervolgens nog wel andere pagina's bezoeken, maar jouw site blijft blanko tenzij ik een nieuwe IE-sessie start. Maar ja, als ik hem nu terug zet op zijn normale cache setting en IE opnieuw start, laat ie al na 2 of 3 keer niets meer zien (nog steeds geen crash trouwens).

Dat is dus 1 van de plaatjes bug, nablijfselen. Zodra je hem krijgt, blijf je er last van houden in de huidige sessie.

woensdag 29 oktober 2003 17:30

Acties:

woensdag 29 oktober 2003 18:34

ja ok, maar waarom krijg ik dan al na 1 keer een reload een probleem met een volledig nieuwe sessie én op cache = every time IE starts ?

To study and not think is a waste. To think and not study is dangerous.

Acties:

Verwijderd

slm schreef op 29 October 2003 @ 17:30:
ja ok, maar waarom krijg ik dan al na 1 keer een reload een probleem met een volledig nieuwe sessie én op cache = every time IE starts ?

Ja heel lomp gezegd, maar MSIE is gewoon buggy wat dat betreft, het wordt gewoon teveel. Ik kan denk ik wel gaan checken op readystate alvorens nieuwe nodes aan te maken, maar ik vermoed en weet wel bijna zeker, dat je dan een zeer trage opbouw krijgt van je in dit geval treeview.

[ Voor 23% gewijzigd door Verwijderd op 29-10-2003 18:36 ]

woensdag 29 oktober 2003 19:33

Acties:

woensdag 29 oktober 2003 20:41

Topicstarter

Ja na een paar reloads op je tree houdt mijn IE er inderdaad mee op. Zit zelf nu met het volgende probleem. Misschien is het wel hetzelfde probleem in de kern:

Op de index van www.shapers.nl worden een boel plaatjes gepreload. Maar als je een beetje vlug bent en voordat de statusbalk (in browser Statusbar) de 100% behaalt, een willekeurige link klikt naar een andere pagina, dan hangt IE. Mocht je het willen testen, kun je ook weer het beste je cache settings op "every visit" zetten, mocht je het de eerste keer niet halen.

Acties:

oh,when?

...

* oh,when? in etter-mode..

<etter="owen">
Gelukkig heeft Flash niet van die suffe problemen...

</etter>

"You're only as good, as what you did last week."

woensdag 29 oktober 2003 21:22

Acties:

woensdag 29 oktober 2003 21:30

Devver

Pixelated

[grotere_etter]

de toekomst van flash:

Afbeeldingslocatie: http://msdn.microsoft.com/ieupdate/graphics/SS_ActiveContentPrompt.jpg

Gelukkig kan je dat met javascript omzeilen

[/grotere_etter]

Intentionally left blank

Acties:

woensdag 29 oktober 2003 21:57

crisp schreef op 29 October 2003 @ 21:22:
[grotere_etter]

de toekomst van flash:

[afbeelding]

Gelukkig kan je dat met javascript omzeilen

[/grotere_etter]

offtopic:
W3C Requests '906 Patent Re-Examination

To study and not think is a waste. To think and not study is dangerous.

Acties:

Verwijderd

oh,when? schreef op 29 October 2003 @ 20:41:
* oh,when? in etter-mode..

<etter="owen">
Gelukkig heeft Flash niet van die suffe problemen...
</etter>

Nu heb ik helaas veel te weinig tijd om veel met Flash bezig te zijn, maar volgens mij ben je voor een beetje component in Flash veel meer tijd kwijt dan met het ontwikkelen van een dhtml component

De laatste keer dat ik aan het AS'en was zat ik te vloeken op de belachelijke implementatie van objecten, en de referenties hierbij in AS. Het was iets met het maken van een nieuwe movieClip iig.

Ik zie in het geval van een treeview de flash movie nog niet breder worden zodra ik nodes ga uitklappen.

Ik vond het overigens wel erg bijzonder dat een flash stuffed macromedia.com wat zo traag was als dikke stront door een rietje heel snel weer werd vervangen door een niet flash oplossing

Nee suf zijn die problemen niet, ...

[ Voor 33% gewijzigd door Verwijderd op 29-10-2003 22:02 ]

woensdag 29 oktober 2003 22:06

Acties:

woensdag 29 oktober 2003 22:19

Devver

Pixelated

Waar ik graag aan toe zou willen voegen dat we het hier niet hebben over een DHTML-probleem, maar de brakke implementatie daarvan in IE (waar overigens nog wat draadjes over lopen). Gelukkig zijn er browsers die wel een goede basis voor DHTML hebben geimplementeerd

_{ok, Moz heeft ook nog wel eens last van memory-leaks, maar niet meer in de mate waarop IE ze nog wel heeft}

[ Voor 19% gewijzigd door crisp op 29-10-2003 22:07 ]

Intentionally left blank

Acties:

oh,when?

...

Verwijderd schreef op 29 oktober 2003 @ 21:57:
Nu heb ik helaas veel te weinig tijd om veel met Flash bezig te zijn, maar volgens mij ben je voor een beetje component in Flash veel meer tijd kwijt dan met het ontwikkelen van een dhtml component

[..]

Ik zie in het geval van een treeview de flash movie nog niet breder worden zodra ik nodes ga uitklappen.

das dan omgekeerd hetzelfde...want ik hou me de laatste tijd totaal niet meer bezig met DHTML, dus het ontwikkelen van een DHTML Component zou mij weer veel meer tijd kosten dan een Flash Component.

owja...over treeview in Flash die breder wordt....

"You're only as good, as what you did last week."

woensdag 29 oktober 2003 22:47

Acties:

Verwijderd

crisp schreef op 29 oktober 2003 @ 22:06:
Waar ik graag aan toe zou willen voegen dat we het hier niet hebben over een DHTML-probleem, maar de brakke implementatie daarvan in IE (waar overigens nog wat draadjes over lopen). Gelukkig zijn er browsers die wel een goede basis voor DHTML hebben geimplementeerd _{ok, Moz heeft ook nog wel eens last van memory-leaks, maar niet meer in de mate waarop IE ze nog wel heeft}

Inderdaad, en laat het kloterige nu realiteit zijn, treeview worden gebruikt in web applicaties, die worden weer gebruik door kantoor mensjes, en die kantoor mensjes gebruiken.... MSIE ... argh..

woensdag 29 oktober 2003 22:51

Acties:

GrimaceODespair

eens een tettenman, altijd ...

Je kan voor de grap ook eens checken wat MSIE (6.0, SP@ hier) aan RAM verzwelgt bij die tree reload. Ik ga hem straks eens laten lopen voordat ik ga slapen, kijken op welke tijd hij blijft steken

Maar hij crasht iig bij de eerste keren nog niet hier.

Wat ik mij trouwens al tijden afvraag, en, misschien is het niet het goede draadje om het in te vragen maar ik doe het lekker toch: wat is het stuk in de http-request waar IE het toch zo moeilijk mee heeft, en dus regelmatig blijft steken (dat stuk dat Windows doet hangen alsof hij van floppy leest)?

edit:
Oh ja, enneuh: DHTML is Flash voor nerds

[ Voor 6% gewijzigd door GrimaceODespair op 29-10-2003 22:53 ]

Wij onderbreken deze thread voor reclame:
http://kalders.be

donderdag 30 oktober 2003 09:43

Acties:

Verwijderd

Dat is ook niet zo verwonderlijk, aangezien je bij een document.location.reload niet de objecten uit het geheugen verwijderd. Objecten worden in Internet Explorer alleen zelfstandig opgeruimd op het moment dat je de sessie beeindigd of, op het moment dat je je window minimaliseert.

Om geheugen lekken te voorkomen (lees verminderen... ) zul je dus gebruik moeten maken van een onunload event handler die de objecten opruimt, en daar was ik nog niet klaar mee.

In de treenode.prototype.remove had ik al wel een aantal zaken ingebouwd mbt het verwijderen van referenties naar objecten zodat de garbage collector van MSIE de boel kan opruimen.

donderdag 30 oktober 2003 20:56

Acties:

Verwijderd

Ik begin alvast een beetje te juichen, maar wel voorzichtig. Ik heb de afbeeldingen nu niet meer toegevoegd als IMG, maar als backgroundImage van een SPAN. Doordat ik de code toch best gestructureerd had opgebouwd was ik hier met een minuutje klaar mee.

Voor zover ik nu kan zien, loopt de treeview niet meer vast

De versie met img.src:
http://members.chello.nl/m.schopman1/bgtree/treeview.html

De versie met span.style.backgroundImage
http://members.chello.nl/.../treewidget/treeview.html

De mensen die evt. gaan testen, laat het eventjes weten

Wat erg apart is om te zien, is dat IE toch wel iets van caching gebruikt voor style.backgroundImage. Als je nl. "every visit to the page" gebruikt, en de treeview inlaad, dan zie je dat het allemaal niet zo snel gaat door het inladen van de images. Zodra je tijdens het expanden van de tree gewoon je settings op "automatically" zet, zie je de snelheid dramatisch toenemen. backgroundImages worden dus ook uit cache gehaald.

Dan wordt het nu tijd voor het minst leuke deel, documenteren

[ Voor 26% gewijzigd door Verwijderd op 30-10-2003 21:01 ]

donderdag 30 oktober 2003 22:30

Acties: