onvoorspelbaar gedrag javascript in firefox

Status
Niet open voor verdere reacties.
(Alweer inloggen ????)

Doctype aangepast.

Wat geëxperimenteerd met <meta http-equiv="Page-Enter" content="blendTrans(Duration=.75)">, maar dat lijkt niets te doen (in IE7).

Ook is "dansende vos" weer terug.
 
Dit is toch wel 'n interessant fenomeen. Maar het blijkt dus niet goed te reproduceren.
Is het mogelijk dat je op een of andere manier alle bestanden van een van die springende albums hier neerzet als zip-file? Of per mail opstuurt? Als je dat zou willen, kan ik m'n mail-adres even doorgeven. Dat geeft de mogelijkheid om 't wat beter te bekijken en zo.
Het zou dan gaan om de bestanden precies zo als ze bij jou zijn. Dus php, css, foto's, alles wat bij 'n bepaald springend album hoort.
 
Los van pogingen om wat rechtstreekser toegang te krijgen of zo is 't wel leuk (denk ik) om hier gewoon door te gaan met dingen die mogelijk ook voor anderen interessant kunnen zijn.
Ik heb nog iets bedacht. 't Lijkt erop dat soms om een of andere reden de header gewoon 'te laat wordt opgemerkt'. De foto staat bovenin het venster, behalve dat daar iets later nog 'n header boven komt. Dus moet de foto weer omhoog: springen. Maar niet altijd.
Zou het kunnen zijn dat om een of andere reden php gewoon niet helemaal goed werkt op de server? Ik weet niet eens of dat kan, maar dat eerst de 'gewone' pagina wordt verstuurd, en dan af en toe de include met vertraging? Of zoiets?
Ik weet niet of dat veel werk is, maar je zou misschien 'n album niet met php kunnen includen, maar met ssi (Server Side Includes). Voor includen werkt dat vrijwel hetzelfde. Als 't dan niet springt, zou dat 'n indicatie kunnen zijn dat 't niet aan de css en zo ligt.
 
Potverdikkeme, mijn antwoord is foetsie!

?????????????????

Goed ik heb het een en ander veranderd aan het bestand. De banner is weg; de eerste includes zijn weg, de tabel is iets hoger gemaakt en ik heb iets ontdekt.

Als de hele pagina in het venster past (geen scrollbalk) dan springt (op dit moment bij mij)
FF niet. Als er wel een scrollbalk is dan springt Firefox soms.

Volgens mij ligt de kern van de zaak toch bij hoe FF met de bladwijzer (named anchor) omgaat. De ene keer lijkt hij alles te hebben en weet hij waar de bladwijzer in het venster moet verschijnen en de andere keer lijkt het alsof hij gewoon bovenaan de pagina begint en dan de bladwijzer gaat zoeken.
 
Ik heb dit topic niet echt gevolgd, maar het gaat erom dat de pagina iets verspringt na het laden nietwaar?

Nu zeg ik misschien iets heel doms, negeer me dan maar, maar als je nou eens gewoon #qqz (als de PHP dit automatisch doet, post dan eens wat PHP code, als je die zelf niet aan kunt passen) achter de url weglaat? Het anchor staat (vrijwel) helemaal bovenaan, als je de pagina laadt zonder anchor, dan wordt ie ook vanaf helemaal bovenaan weergegeven. Dan is er toch geen probleem?

En het is toch ook logisch dat de pagina alleen verspringen kan als de hoogte van de pagina groter is dan de hoogte van de inhoud? Dat het dus niet altijd hoeft te gebeuren dat de pagina verspringt.

Maar ik heb het idee, dat csshunter en Goeroeboeroe dat ook wel door zouden hebben, dus waarschijnlijk heb ik het probleem niet helemaal begrepen...

[EDIT]
En wellicht helpt het ook om op de <body> (en eventueel de <html>) even padding: 0px en margin: 0px toe te voegen, aangezien het anchor wel bovenaan staat in de body, maar als er 10px padding in zit, zal de pagina toch 10px "verspringen".
[/EDIT]
 
Laatst bewerkt:
Het gaat om de albums die op deze pagina onder 'schepen albums' vermeld staan.

Kijk eerst stond er wel wat boven dat anker en dat wil ik daar ook graag weer terug hebben. Het is alleen maar weg, om te zien of dat helpt.
 
Maar (sorry dat ik zo in dit topic inbreek hoor), leg me dan eens uit wat precies het probleem is. Je hebt content boven de foto staan. Je linkt naar de pagina met de foto, waarbij het de bedoeling is dat er naar het anker gesprongen wordt. Dan is het toch logisch dat de pagina verspringt? Of wil je dat de pagina bij het laden meteen vanaf het anker weergegeven wordt?

Ik heb er namelijk nog nooit van gehoord dat dat mogelijk is... :confused:
 
't Probleem is dat hij af en toe wel en af en toe niet verspringt. En daar is geen regelmaat in te vinden. Mogelijk dat jij het probleem dus helemaal niet ziet.
Soms komt de foto halverwege het venster te staan, en springt dan omhoog. De volgende keer kan diezelfde foto prima in een keer op de goede plaats staan. JavaScript aan/uit en cache leeg/vol maakt niet uit.
Dat is 't in 'n peulenschil. En anders ben ik bang dat je toch even 't hele topic moet lezen. Ideeën zijn natuurlijk altijd welkom, want tot nu toe hebben we geen flauw idee wat er misgaat.
't Zou ook nog 'n bug in Firefox kunnen zijn, wie weet...
 
Hmm, dan ben ik bang dat ik het echte probleem inderdaad nog niet waargenomen heb. Het enige wat ik kan zien is een verspringing van +/- 10px, die mij logisch verklaarbaar lijkt door de padding in de body.

Maar als dat niet het probleem is, dan houd ik mij weer even gedeisd, want ik heb ook geen idee wat het probleem dan zou zijn. :confused:
 
Of wil je dat de pagina bij het laden meteen vanaf het anker weergegeven wordt?
JA of liever gezegd: ik wil dat de pagina van een bepaald punt af weergegeven wordt en ik wist niet beter dan daarvoor een anker te kiezen.

Ik heb er namelijk nog nooit van gehoord dat dat mogelijk is...
Het lijkt erop als of het af en toe wel mogelijk is en aangezien computers niet at random behoren te werken, trachten we uit te zoeken waarom dat nu wel lijkt te gebeuren.
 
Laatst bewerkt:
een verspringing van +/- 10px, die mij logisch verklaarbaar lijkt door de padding in de body.
Padding in de body???
Ik zocht maar vond niet!
Heb ik niet goed gezocht?
 
Het is meestal slim om in de body de padding en margin op 0 te zetten, omdat verschillende browsers verschillende standaardwaarden hebben. (Sommige mensen zetten trouwens nog veel meer op 0 om die reden). Maar dat is 'n heel klein beetje en hoort bovendien niet tot verspringen te leiden. Dan staat 't gewoon in de ene browser iets lager.
't Gaat hier om verspringingen van wel 200-300 px.
 
Bedankt voor de informatie!

Dan gaan we nu maar weer verder waar we gebleven waren en ik ben zo vrij dat dus even te herhalen.
Goed ik heb het een en ander veranderd aan het bestand. De banner is weg; de eerste includes zijn weg, de tabel is iets hoger gemaakt en ik heb iets ontdekt.

Als de hele pagina in het venster past (geen scrollbalk) dan springt (op dit moment bij mij)
FF niet. Als er wel een scrollbalk is dan springt Firefox soms.

Volgens mij ligt de kern van de zaak toch bij hoe FF met de bladwijzer (named anchor) omgaat. De ene keer lijkt hij alles te hebben en weet hij waar de bladwijzer in het venster moet verschijnen en de andere keer lijkt het alsof hij gewoon bovenaan de pagina begint en dan de bladwijzer gaat zoeken.
 
Eerst even over de ontdekking: bij mij en bij csshunter versprong hij juist als 't venster groot was, en niet als het klein was.
Ik heb die code bekeken die je hebt gestuurd, maar daar zie ik geen vreemde dingen in of zo. Nou zegt dat ook niet zoveel, want ik ben bepaald geen php of sql-expert.
En zonder dat 't echt draait met foto's en css en alle toeters en bellen vind ik 't nog extra lastig.
Ik ben bang dat ik er op deze manier niet achter kom. Iemand anders?
't Doet me trouwens sterkt denken aan 'n bug die IE 6 (of 7?) ooit had. Ik weet 'm niet meer precies, want ik gebruik nooit @import, maar 't was iets van als je 'n link naar 'n style in je head had, én 'n @import, en ook nog 'n stukje style in de head zelf, en dat in 'n bepaalde volgorde, dan werd de pagina eerst zonder css getoond en dan nog 'ns mét css. Dat waren sprongen waar de jouwe niets bij zijn.
Voorzover ik heb kunnen zien gebeurt 't alleen in Firefox. 't Zou dus toch wel 'n bug in FIrefox kunnen zijn.

<off-topic @csshunter>
Ken je Text Extension? 'n Extensie om extensies te updaten voor nieuwe versies. Als 't niet werkt, kun je ze weer 'terug-daten'. Werkte bij mij perfect om vrijwel alle extensies te kunnen blijven gebruiken. Meestal is 't alleen maar de versie die even veranderd moet worden.
O, en nu je 't zegt: nou begrijp ik waarom ik zo onrustig heb geslapen vannacht!
</off-topic @csshunter>
 
Laatst bewerkt:
Wat is die CSShunter stilletjes opeens...
Nou, die zat dus stilletjes zonder op of om te kijken te spelen met springende scheepjes, en heeft de ganse discussie van vandaag gemist. Maar hier ben ik weer. En mijn relaas gaat als volgt:

Hallo dames en heren ook, ik was nog niet ten einde raad, hoor. ;)
En kan het net als o.a. Pieter ook niet uitstaan als machines mij de baas lijken te zijn.
Aanpak:
  • "Isoleer het probleem in de meest eenvoudige vorm waarin het zich nog net voordoet, en probeer dan de analyse te maken." Elimineren die hap!
  • Aldus eerst een pagina helemaal gestript: lege tabellen met alleen maar breedte en hoogte plus een randje om te zien waar je zit, geen images, en alle verdere code eruit gehaald.
  • Daarmee werkte hij goed! :)
  • Toen stuk voor stuk alles er weer voorzichtig in geplakt, telkens kijken of hij het nog goed bleef doen > ja hoor, dat ging goed ... tot bijna op het eind.
Diagnose:
  • Wat blijkt: het is het script van het tellertje dat de vaste grond onder het anker vandaan haalt! Als je dat uit-commentarieert, doet ie het gewoon. :)
Analyse:
  • Van javascript heb ik nauwelijks enige sjoege, en dit script is ook nog eens uitermate dicht op elkaar gecomprimeerd (alles stuik op 1 regel gezet), zodat ik er helemaal geen zicht op heb.
  • Mijn vermoeden is, dat het tellertje op een of andere manier iets uithaalt met de bladwijzers in een pagina > bv. in verband met het verhinderen van dubbeltellingen van bezoek op een pagina: "kijken of een bladwijzer is geklikt, en zo ja dan negeren." Of dat zo is, mogen onze javascript-deskundigen bekijken!
Conclusie:
  • We hebben dus nu een alternatief voor het naar boven verplaatsen van de foto.
  • Dat is dan: het tellertjesscript niet gebruiken.
  • Ik zie dat vlak onder de script-trigger er ook een <noscript> telmethode in staat, dan zal ie dus toch wat tellen (of die hetzelfde werkt of minder gedétailleerd is, weet ik niet). Dus met het tevens weghalen van de <noscript></noscript> tags is het probleem weg, en kan in elk geval nog iets van bezoek op deze album-pagina's geteld worden, misschien dus iets minder zuiver.
  • De mensch wint van de machine!

Hiephoi,
CSShunter (was ik aan het handtekenen, totdat ...)

Hoei! :(
Nog even bewonderend willen kijken naar de nu geuploade file'tjes ... hij springt weer! :evil:
Oftewel: eerst spong ie ook lokaal, en lokaal doet ie nu het goed, maar via www weer niet. :o
Daar word je toch helemaal turelurefluut van! Bliksekaters! Dat verzin je toch niet! Enzovoorts: lucht happen en rustig proberen te blijven.

Dan ...
... begint dus het hele proces weer overnieuw ....

Diagnose:
  • Nieuw verschijnsel: het tellerscriptje kan er rustig in blijven staan, maar nu is het ... het "document.write('')" script, dat (als javascript aanstaat) behulpzaam komt vertellen dat je ook de pijltjestoetsen kunt gebruiken. :eek:
  • Dat scriptstukje eruit, en weer normaal zoals het hoort. :rolleyes:
  • Zo, dan gaan we dat eens met een vergrootglas bekijken.
  • Qua code niets vreemds mee aan de hand. Er staan een paar overbodige escapes in, maar beter teveel escapes dan te weinig. Dus er nog maar eens een paar extra bij gezet bij waar er haakjes stonden - zou niet moeten moeten, maar je weet het nooit. Nee hoor, niets: springlevend! :confused:
Dan maar iets heel simpels proberen:
HTML:
<script type="text/javascript"> 
	document.write('boe');
</script>
Dat heb ik geweten: onze koe maakte weer vrolijk een luchtsprong!
Dan doen we nog eenvoudiger, gewoon met niks:
HTML:
<script type="text/javascript"></script>
Kijk, dat ging er in als zoete koe: keurig op zijn plaats.
  • Voor het bewijs uit het ongerijmde: van de document.write een functie gemaakt en die in de head gezet, en dan ter plekke op de pagina die functie oproepen: nee, daar trapte onze FF niet in.
Analyse
  • Toch weer een script! Interferentie? Allebei de andere scripts (die van het tellertje en van de key-logger) uitgezet. - Spring! (en geluid van brekende klompen). Zou dan Firefox toch een bugje hebben? Ik was dit verschijnsel nog nooit tegengekomen.
  • Misschien dat het aan de combinatie van d.write en de tabel-structuur ligt? Voor experimenteerlustigen onder de lezers: een vergelijkend testje met een tabel-opmaak en een pure div-opmaak zou er best in gaan.
  • O, tussen haakjes, tussendoor ook nog een strict DOCtype er boven geplakt; ook de los zwevende anker-tag (vóór de tabel waar het om gaat: <a name="qqz"></a>) binnen de <tr> van de onderhavige img gehaald; en ook aan de <img> zelf vastgeplakt. - Maakt allemaal niets uit. Mmm.
Nieuwe conclusie:
  • De document.write mogelijkheid voor het tonen van de gebruiksaanwijzing pijltjes-navigatie valt af.
  • Dan verzinnen we wat anders: de betreffende regels niet als javascript-tekst opnemen, maar gewoon als html-tekst op de pagina: met een ID'tje dat 'm via css tot {display: none;} brengt. Met javascript kan dan de style-wisseling naar {display: block;} gemaakt worden. Die functie maar eens opgenomen als onload-activiteit.
En laat dat nou werken! :D (alle wijzigingen zitten alleen in de 3 parallele html-bestanden, zie broncode; alle toebehoren in de achterliggende mapjes zijn onveranderd).
Kunnen we toch zeggen: de mensch wint het van de machine!

Hiephoi!
CSShunter

PS1: De foto komt nu keurig snel op zijn goede plaats tevoorschijn. Het zichtbaar worden van de {display: block;} komt nu wat achteraan hobbelen, omdat eerst de rest klaar moet zijn voordat de onlaod getriggerd wordt.

PS2: Ook nog even geprobeerd om de functie meteen na het #scriptOnly tekstblokje (in de html zelf ipv als onload) op te nemen: misschien zou dat net iets vlugger gaan. Nou, niet dus, dwz. dan is de tekst er inderdaad sneller, maar ... springt hij weer op en neer tegen het plafond!

PS3: Voor als alles zou mislukken was er ook nog de iframe oplossing achter de hand: lang niet ideaal, maar als FF de inhoud van een iframe zou laten dansen, zou ik toch wel heel verbaasd opkijken.

PS4:
O, schiet me het Columbus-ei te binnen. Wat je ook zou kunnen doen, is de pijltjestekst gewoon helemaal niet als script-aangedreven vertoning presenteren, maar gewoon altijd laten zien. Met er onder een verontschuldigend regeltje "als 'Javascript' op uw computer uit staat, werkt deze toetsenbediening niet". Dan ben je er ook van af. :cool:

PS5:
O, Pieter: ik heb voor IE de "blendTrans(Duration=1.5)" gemaakt, dan gaat het beter zoals je hopelijk ziet.

PS6:
O, <off-topic @Oeroeboeroe>die Text Extension ken ik niet, zal eens aan snuffelen. Bedankt voor de tip!

PS7:
Eh, <off-topic@all>hij stopt nu met PS'sen. En de emoticons zijn op. :D
 
Dat is een heel verhaal.
Ik zal het nog eens rustig over moeten lezen en op me in moeten laten werken.
Tot later vandaag.
 
# De document.write mogelijkheid voor het tonen van de gebruiksaanwijzing pijltjes-navigatie valt af.
Een GEWELDIGE conclusie!

Ik heb dat stukje script verwijderd en inderdaad de vuurvos houdt op met huppelen.
Ook de IE voorziening toegevoegd.
Nu nog de rest van het bestand een beetje opschonen en het kan er voor een jaar wat dienst doen.

Jullie ALLEN bedankt voor alle moeite.

Rest me nog één ding.
Deze post staat nu onder "link rel=prefetch href=volgende", maar het probleem dat opgelost is, is heel andere koek. Moet daar iets aangedaan worden?
 
gefeliciteerd CSShunter
ik was er nooit achtergekomen XD
mij teveel gedoe met JS, dit beheers ik totaal niet XD.
mooi dat het gelukt is :D
 
csshunter, petje af! Dat had ik je niet nagedaan, zoveel spitwerk. Complimenten!
En inderdaad, ik dacht dat je 't weekend weg was of zo.
Ik heb nog twee dingetjes.
Bij mij sprong hij dus ook als ik JavaScript uit had staan. Dus dat begrijp ik niet. Of wacht 'ns even, ik zet 't uit met NoScript. Dat zou betekenen dat NoScript niet ál het JavaScript uitschakelt? Ik heb JavaScript dus vrij snel laten vallen als oorzaak omdat dat geen invloed leek te hebben.
Nog 'n vraagje: hoe heb jij die code gekregen? Heb je gewoon drie pagina's van internet geplukt? Dat lukte mij niet zo snel, maar misschien heb ik 't niet genoeg geprobeerd.

Wat betreft 't opgelost: Pieter, misschien kun je 't onderwerp veranderen? Ik ben daar ook niet zo in thuis.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan