[IE8] Zoekt javascript op de verkeerde plaats

[Mac_Cain13]

Misschien, of waarschijnlijk zelfs, zijn jullie op de hoogte van het feit dat IE8 niet altijd op de juiste plaats naar javascriptjes zoekt als je gebruik maakt van een base-tag. Het relatieve pad van je javascript wordt dan gewoon in de huidige map gezocht, in plaats van via de opgegeven base.

Erg vervelend, maar gelukkig vond ik een MSDN topic hierover. Waarin wordt geopperd een tweede maal de base in de HTML te zetten:

HTML:

<base href="http://foo.com/base">
<script text="script/javascript" src="script1.js"></script>
<base href="http://foo.com/base">
<script text="script/javascript" src="script2.js"></script>
<script text="script/javascript" src="script3.js"></script>
<script text="script/javascript" src="script4.js"></script>

Het lijkt met deze workaround opgelost in een enkel project waar dit nu in is gezet. Echter is het natuurlijk een nare oplossing iets nu redundant te moeten doen in de HTML.

Gezien ik op GoT geen topic over dit probleem kon vinden en Google me niet veel meer dan dit ene topic opleverde, mijn vraag aan jullie: hebben jullie andere oplossingen voor dit probleem? Zijn jullie bekend met andere workarounds en hebben jullie een verklaring voor de keuze van de IE8 devvers? Of is dit domweg een bug die gefixed moet worden.

[Johnny]

Ik zie het ook regelmatig in maar error logs, maar weet niet of IE8 de enige browser is die hier last van heeft, ik dacht dat het vooral gare crawlers/bots waren.

Het is wel aan te raden nog / aan het einde van je base href te zetten, daar kunnen andere browsers/crawlers ook de mist mee in gaan. Wat altijd werkt zijn absolute paden gebruiken, ookal staat het niet zo netjes in je code.

[dB90]

En dit?

<base href="http://foo.com/base"><!--[if IE]></base><![endif]-->

[ Voor 16% gewijzigd door dB90 op 15-06-2009 23:45 ]

[Bosmonster]

text="script/javascript"

bedoel je niet type="text/javascript" ?

dB90 schreef op maandag 15 juni 2009 @ 23:44:
En dit?

<base href="http://foo.com/base"><!--[if IE]></base><![endif]-->

Dat zou alleen voor IE6 nodig moeten zijn.

Verder heb ik wat IE8 betreft nog nooit van deze 'bug' gehoord. Wij gebruiken base-href in zo goed als iedere website, maar nog nooit last mee gehad in IE8.

[ Voor 72% gewijzigd door Bosmonster op 16-06-2009 00:08 ]

[Mac_Cain13]

Mja, sorry mensen. Ik was lui en deed een copy & paste vanaf het MSDN forum. Mijn eigen (in IE8 werkende) code heeft die rariteiten van hierboven niet:

HTML:

<base href="http://www.spiegelpaleis.nl/" />
<script type="text/javascript" src="js/sifr.js"></script>
<base href="http://www.spiegelpaleis.nl/" />
<script type="text/javascript" src="js/celer/celer.js"></script>
<script type="text/javascript" src="js/jquery.js"></script>
<script type="text/javascript" src="js/jquery.tooltip.min.js"></script>
<script type="text/javascript" src="js/jquery.selectboxes.js"></script>

Zonder die 2e base gaat IE8 dus de javascript op de verkeerde locatie zoeken.

De base sluiten met </base> en een net type attribuut doen 't hem dus niet. Ik heb inderdaad ook wel eens een crawler dit soort errors zien genereren, maar dat IE8 het doet is vervelender. Aangezien de site er minder goed van gaat werken..

@Johnny; Gebruik je ook een workaround nu? Of los je het domweg niet op?

[ Voor 5% gewijzigd door Mac_Cain13 op 16-06-2009 00:12 ]

[TeeDee]

Mac_Cain13 schreef op dinsdag 16 juni 2009 @ 00:11:

Buiten het feit dat je site er minder goed van gaat werken ('t is een utopie maar goed): het setten van een 2e base is van de zotte. Zoals ook al Bosmonster zegt: ben hier alleen tegenaan gelopen in IE6 en de <base> gebruik ik ook in heel wat sites.

[ Voor 57% gewijzigd door TeeDee op 16-06-2009 00:22 ]

[TheRookie]

Heb geen verstand van JS, maar kan het niet zo zijn dat in die sifr.js de base aangepast wordt ?

[Bosmonster]

Ik ben nog steeds wel benieuwd naar een concreet online voorbeeld overigens, want zoals ik al zei, ben dit probleem nog nooit zelf tegengekomen.

[Johnny]

Mac_Cain13 schreef op dinsdag 16 juni 2009 @ 00:11:
@Johnny; Gebruik je ook een workaround nu? Of los je het domweg niet op?

Ik heb nog geen klachten gehad van IE8 gebruikers, en dus ook nog geen aanleiding gehad om het te onderzoeken. Als ik het goed begrijp laden de pagina's in jouw geval wel correct maar doet IE8 ook nog een request naar de verkeerde locaties?

[Mac_Cain13]

Bosmonster schreef op dinsdag 16 juni 2009 @ 15:05:
Ik ben nog steeds wel benieuwd naar een concreet online voorbeeld overigens, want zoals ik al zei, ben dit probleem nog nooit zelf tegengekomen.

Een gefixte variant kun je vinden bij Spiegelpaleis en een nog niet gefixte variant bij X Products. Van deze laatste site vind ik dus regelmatig 404's gegenereerd door IE8 terug in de log naar JavaScriptjes in de verkeerde map.

Sommige IE gebruikers klagen dat de site traag is of niet werkt op JavaScript onderdelen, maar ik heb dit niet kunnen reproduceren. Zodra de extra base erin staat verdwijnen de 404's en de klachten van gebruikers. Van mensen met andere browsers hoor ik geen klachten.

Enorm vaag, omdat het me lijkt dat heel veel mensen hier last van zouden moeten hebben als dit zich voor doet bij een base-tag icm javascript..

[Bosmonster]

Mac_Cain13 schreef op woensdag 17 juni 2009 @ 10:49:
[...]

Een gefixte variant kun je vinden bij Spiegelpaleis en een nog niet gefixte variant bij X Products. Van deze laatste site vind ik dus regelmatig 404's gegenereerd door IE8 terug in de log naar JavaScriptjes in de verkeerde map.

Sommige IE gebruikers klagen dat de site traag is of niet werkt op JavaScript onderdelen, maar ik heb dit niet kunnen reproduceren. Zodra de extra base erin staat verdwijnen de 404's en de klachten van gebruikers. Van mensen met andere browsers hoor ik geen klachten.

Enorm vaag, omdat het me lijkt dat heel veel mensen hier last van zouden moeten hebben als dit zich voor doet bij een base-tag icm javascript..

Bij xproducts.nl krijg ik met IE8 geen problemen en geen 404's.

Edit: hmm bij een beetje rondklikken krijg ik inderdaad een 404 in de logs te zien. Ik krijg geen errors omdat de scripts al in de cache zitten van de homepage, maar kan me voorstellen dat het script-errors op kan leveren als je op een onderliggende url binnenkomt of je cache uit hebt staan.

Op die site doet het probleem zich ook alleen voor met 'js/thickbox.js?rev2'. De andere scripts pakt ie wel gewoon goed... weird.

Het vreemde is ook dat ie soms daarna wel alsnog de juiste url oppakt (en uit zichzelf blijkbaar besluit het script nog maar een keer proberen te laden ) en soms niet.

Weer een mooi staaltje MS logica

[ Voor 36% gewijzigd door Bosmonster op 17-06-2009 11:12 ]

[Mac_Cain13]

Bosmonster schreef op woensdag 17 juni 2009 @ 11:05:
[...]


Bij xproducts.nl krijg ik met IE8 geen problemen en geen 404's.

Edit: hmm bij een beetje rondklikken krijg ik inderdaad een 404 in de logs te zien. Ik krijg geen errors omdat de scripts al in de cache zitten van de homepage, maar kan me voorstellen dat het script-errors op kan leveren als je op een onderliggende url binnenkomt of je cache uit hebt staan.

Op die site doet het probleem zich ook alleen voor met 'js/thickbox.js?rev2'. De andere scripts pakt ie wel gewoon goed... weird.

Het vreemde is ook dat ie soms daarna wel alsnog de juiste url oppakt (en uit zichzelf blijkbaar besluit het script nog maar een keer proberen te laden ) en soms niet.

Weer een mooi staaltje MS logica

Bedankt voor het testen, echt gaar dat het zo onvoorspelbaar is. Dat het alleen met thickbox.js problemen geeft heeft te maken met dat de eerst genoemde script-tag het wel doet en die daarna niet. Het lijkt dus dat IE de base even is vergeten voor de JS of iets dergelijks.

Met een extra base onder de eerste script-tag blijft het wel hangen. Alleen waarom? Geen idee.

Info en tips blijven welkom, maar ik ga ook eens een bugreportje invullen bij MS denk ik.. Geen touw aan vast te knopen zo.

[Borizz]

Mac_Cain13 schreef op woensdag 17 juni 2009 @ 22:42:
[...]
Bedankt voor het testen, echt gaar dat het zo onvoorspelbaar is. Dat het alleen met thickbox.js problemen geeft heeft te maken met dat de eerst genoemde script-tag het wel doet en die daarna niet. Het lijkt dus dat IE de base even is vergeten voor de JS of iets dergelijks.

Met een extra base onder de eerste script-tag blijft het wel hangen. Alleen waarom? Geen idee.

Info en tips blijven welkom, maar ik ga ook eens een bugreportje invullen bij MS denk ik.. Geen touw aan vast te knopen zo.

Interessant probleem. Treedt het probleem ook op als je i.p.v. sifr.js een ander script als eerst inlaad? Misschien wordt het probleem getriggerd door bepaalde JavaScript code. Aan de voorbeeldsites die je opgeeft te zien, lijkt het probleem zich ook met andere scripts voor te doen.

Wellicht dat dit nog de netste workaround is dan:

HTML:

<base href="http://www.spiegelpaleis.nl/">
<script type="text/javascript" src="js/sifr.js"></script>
<!--[if IE 8]><base href="http://www.spiegelpaleis.nl/"><![endif]-->
<script type="text/javascript" src="js/celer/celer.js"></script>
<script type="text/javascript" src="js/jquery.js"></script>
<script type="text/javascript" src="js/jquery.tooltip.min.js"></script>
<script type="text/javascript" src="js/jquery.selectboxes.js"></script>

[R4gnax]

Mac_Cain13 schreef op woensdag 17 juni 2009 @ 22:42:
[...]
Bedankt voor het testen, echt gaar dat het zo onvoorspelbaar is. Dat het alleen met thickbox.js problemen geeft heeft te maken met dat de eerst genoemde script-tag het wel doet en die daarna niet. Het lijkt dus dat IE de base even is vergeten voor de JS of iets dergelijks.

Met een extra base onder de eerste script-tag blijft het wel hangen. Alleen waarom? Geen idee.

Info en tips blijven welkom, maar ik ga ook eens een bugreportje invullen bij MS denk ik.. Geen touw aan vast te knopen zo.

Zomaar een idee: probeer de script tags eens in de body te zetten ipv in de head. Misschien is er iets raars met de volgorde waarmee de tags in de head sectie door de parser in IE8 verwerkt worden?

[eamelink]

Ter referentie; dit is een bug in de IE8 Lookahead downloader. Die vergeet de base href. Het heeft bij de bezoeker niet zo'n impact, omdat de goede url alsnog geladen wordt in een later stadium. Voor dynamische sites kan het vervelend zijn, omdat er mogelijk (veel) dynamische pagina's gegenereerd worden door de requests naar niet bestaande urls.

Meer info, zie http://blogs.msdn.com/iei...Lookahead-Downloader.aspx