[JavaScript] FireFox begrijpt pop-up niet

[Cavorka]

Sinds gisteren werk ik met FireFox ipv met IE en het bevalt tot nu toe zeer goed, vooral de lichtheid in vergelijking met IE (lompe bende) is zeer aangenaam.

Echter nu was ik mijn eigen website aan het testen, en wat schetst mijn verbazing: om duistere redenen pakt FF mijn javascript pop-up niet. Ik heb hem (uiteraard) getest in IE en Opera, en daar werkt ie perfect.

code:

function OpenWindow(title, group, id, height, width, scroll, nr, size, imwidth) {
var title, group, id, height, width, scroll, nr, size ;
var filename = './popup.php?nr=' + nr + '&path=' + id + '&title=' + title + '&g=' + group + '&s=' + size + '&w=' + imwidth ;
var configz = (...) <= veel config, even weggehaald voor de layout, daar ligt het niet aan
window.open(filename, 'title', configz);
}

Welke wordt aangeroepen met bijvoorbeeld:

code:

onclick="OpenWindow('Alfa Romeo Monza 8C 2300','Cars','alfaromeo','635','905','yes','2','39','1072')"

Zoals je ziet open ik dus popup.php met een aantal parameters zodat hij wat statistiekjes kan regelen en zodat de pop-up de goede title krijgt. Maar de enige variabele die ik door krijg is 'nr', de rest wordt niet meegezonden (getest met een eenvoudige print van deze $_GET variabelen). Is dit een bekend probleem? Ik krijg namelijk helemaal geen errors, of warnings van FF (Dev Edition).

Hartelijk dank voor de input.

[ Voor 54% gewijzigd door Cavorka op 28-05-2004 13:01 ]

[André]

Misschien moet je in de 3de regel & amp; vervangen door & ?

[Osiris]

Misschien te simpel gedacht hoor, maar komt het wellicht door de popup-blocker van FF?

[Arnout]

Osiris schreef op 28 mei 2004 @ 13:06:
Misschien te simpel gedacht hoor, maar komt het wellicht door de popup-blocker van FF?

Nee, want die laat zulke javascript popups gewoon door.

[ Voor 4% gewijzigd door Arnout op 28-05-2004 13:08 ]

[André]

Osiris schreef op 28 mei 2004 @ 13:06:
Misschien te simpel gedacht hoor, maar komt het wellicht door de popup-blocker van FF?

Had ik ook aan gedacht, maar hij zei dat 'nr' wel doorgegeven werd dus dan is er wel een popup.

[Cavorka]

Andre: Zou kunnen, maar dan is mijn website niet meer XHTML compliant. Ik zal het even testen.

Osiris: Zou ook kunnen, maar er komt wel een pop-up tevoorschijn. En hij is toch niet zo dom dat hij pop-ups blokeert ook als ik zelf op een link klik? Dan zou elke target='_blank' ook niet moeten werken.

*Edit: Ah damned, Andre had gelijk. Ja dat is dus weer erg lekker. Heb je net de W3C standaard nageleefd, begrijpt FF het niet.

[ Voor 27% gewijzigd door Cavorka op 28-05-2004 13:12 ]

[Osiris]

Hmm, ok, my bad

[André]

Cavorka schreef op 28 mei 2004 @ 13:09:
Andre: Zou kunnen, maar dan is mijn website niet meer XHTML compliant. Ik zal het even testen.

Osiris: Zou ook kunnen, maar er komt wel een pop-up tevoorschijn. En hij is toch niet zo dom dat hij pop-ups blokeert ook als ik zelf op een link klik? Dan zou elke target='_blank' ook niet moeten werken.

Wat zie je als je de url van die popup bekijkt?

[Cavorka]

Als ik de &'s erin laat staan, dan staan die ook in de URL van de pop-up (bij FF) en werkt het dus niet, als ik ze vervang door &'s dan werkt het zoals het moet.

Ik ga even kijken of ik door de mazen van de W3C kan zwemmen, omdat dit in een javascript gedeelte staat en dus niet gechecked zou moeten worden door de Validator.

Edit: Nee, helaas. Dat is best wel erg *** eigenlijk.

code:

Line 380, column 42: cannot generate system identifier for general entity "path"

...ilename = './popup.php?nr=' + nr + '&path=' + id + '&title=' + title + '&g='...
etc.

[ Voor 37% gewijzigd door Cavorka op 28-05-2004 13:18 ]

[Verwijderd]

Cavorka schreef op 28 mei 2004 @ 13:14:
Als ik de &'s erin laat staan, dan staan die ook in de URL van de pop-up (bij FF) en werkt het dus niet, als ik ze vervang door &'s dan werkt het zoals het moet.

Ik ga even kijken of ik door de mazen van de W3C kan zwemmen, omdat dit in een javascript gedeelte staat en dus niet gechecked zou moeten worden door de Validator.

Je zou CDATA tags kunnen gebruiken...of een extern JS bestand met de OpenWindow functie.
http://www.w3schools.com/xml/xml_cdata.asp

HTML:

<script>
<![CDATA[
function matchwo(a,b) {
    if (a < b && a < 0) then 
        return 1
    else 
        return 0
}
]]>
</script>

[André]

Waarom is dat valideren altijd zo belangrijk?

En als je & vervangt door %26 ?

[Cavorka]

André schreef op 28 mei 2004 @ 13:21:
Waarom is dat valideren altijd zo belangrijk?

En als je & vervangt door %26 ?

Waar heb je anders standaarden voor? Als ik nu gewoon &'s zou gaan gebruiken dan had ik net zo goed mijn hele website niet XHTML compliant kunnen maken.

En dat CDATA werkt bij mij niet, mijn hele functie doet dan helemaal niets meer... Extern .js bestand is inderdaad nog wel een optie, maar dat is wel een laatste uitweg. Het lijkt me toch dat FF gewoon moet werken. Anders ga ik ze wel even lastig vallen met een e-mailtje, want ik vind dit best wel prutserig van FF.

[ Voor 24% gewijzigd door Cavorka op 28-05-2004 13:29 ]

[André]

Cavorka schreef op 28 mei 2004 @ 13:26:
[...]

Waar heb je anders standaarden voor? Als ik nu gewoon &'s zou gaan gebruiken dan had ik net zo goed mijn hele website niet XHTML compliant kunnen maken.

idd, dan had je net zo goed je hele website niet XHTML compliant kunnen maken

Is het zo dat de functionaliteit minder wordt als je & gebruikt? Nee, en toch wil je het met alle geweld valideren?

[Cavorka]

Je hebt wel gelijk, maar het is wel een beetje omgekeerde wereld zeg. Pfff, je website expres niet compliant maken, want anders werkt het niet. Het is inderdaad de oplossing, maar gadverdamme, wat voor een browserwereld leven we in? *steekt armen wanhopig de lucht in* + +

[ Voor 4% gewijzigd door Cavorka op 28-05-2004 13:33 ]

[André]

Cavorka schreef op 28 mei 2004 @ 13:32:
Je hebt wel gelijk, maar het is wel een beetje omgekeerde wereld zeg. Pfff, je website expres niet compliant maken, want anders werkt het niet. Het is inderdaad de oplossing, maar gadverdamme, wat voor een browserwereld leven we in? *steekt armen wanhopig de lucht in* + +

* André troost Cavorka

En die %26 zoals ik al zei?

[RM-rf]

André schreef op 28 mei 2004 @ 13:34:
[...]

* André troost Cavorka

En die %26 zoals ik al zei?

zou je je niet eerst afvragen waarvoor je iets doet, het is een URI, %26 en &, zijn daarin toch echt wel wat anders, URL = 'pagina.cgi?blaat=blaat&foo=bar' is wat anders dan location = 'pagina.cgi?blaat=blaat%26foo=bar' .

hou liever vast aan die &, dat voorkomt problemen, zeker in explorer (probeer maar eens 'pagina.cgi?blaat=blaat&regdatum=bar' als location te versturen, [benieuwd of die ook in explorer 6 nog steeds misgaat])

wat betreft het script, plaats voor de winow.open() een een alert van de waardes die je ook aan de window open wilt doorgeven,
als die ook niet uitgevoerd wordt zit je fout ergens daarvoor al

[ Voor 7% gewijzigd door RM-rf op 28-05-2004 13:42 ]

[Cavorka]

%26 doet exact hetzelfde als de

code:

&

, werkt dus helaas niet.

Thanks voor het troosten, maar soms word ik er zo moedeloos van.

Ik ga maar even wat posten op het Mozilla/Firefox Bugs Forum.

[ Voor 9% gewijzigd door Cavorka op 28-05-2004 14:10 ]

[Verwijderd]

Cavorka schreef op 28 mei 2004 @ 13:26:
En dat CDATA werkt bij mij niet, mijn hele functie doet dan helemaal niets meer... Extern .js bestand is inderdaad nog wel een optie, maar dat is wel een laatste uitweg. Het lijkt me toch dat FF gewoon moet werken. Anders ga ik ze wel even lastig vallen met een e-mailtje, want ik vind dit best wel prutserig van FF.

Waarom zou je in niet je JS in een extern bestand willen hebben?

[André]

Verwijderd schreef op 28 mei 2004 @ 13:51:
[...]

Waarom zou je in niet je JS in een extern bestand willen hebben?

Dus als inline js niet gevalideerd wordt zetten we het maar extern, dat vind ik echt de grootste onzin, je houdt jezelf dan voor de gek met je validatie.

[AkaXakA]

Oh...die validator gaat over xhtml, niet js! En bovendien, als je inline js zet _moet_ het tussen CDATA tags, anders ben je eigenlijk niet compliant..(vond ik ook wel raar toen ik voor het eerst las dat dat moest, maar ja)

En het extern hebben van je js is alleen maar handig en juist het hele idee achter het markup, style and logic (i.e. xhtml, css en js.)

Dus zet het gewoon in een .js, en roep het goed aan.

[Cavorka]

@André: Inderdaad, alle oplossingen hier genoemd werken wel, maarja... Het is eigenlijk allemaal om het probleem heen fietsen.

@AkaXakA: Zoals gezegd: bij mij werkt het dan helemaal niet meer. Hele functie doet dan niets in FF. En js extern hebben kan handig zijn, echter vaak genoeg genereer ik mijn javascript (en CSS ook trouwens) met behulp van PHP dus dan is dat geen optie.

En het moet niet per se tussen die CDATA tags, aangezien ik de validator er nog nooit iets heb over horen zeggen, geen warning, geen error, niets.

[ Voor 18% gewijzigd door Cavorka op 28-05-2004 14:10 ]

[André]

Cavorka schreef op 28 mei 2004 @ 14:06:

@AkaXakA: Zoals gezegd: bij mij werkt het dan helemaal niet meer. Hele functie doet dan niets in FF. En js extern hebben kan handig zijn, echter vaak genoeg genereer ik mijn javascript (en CSS ook trouwens) met behulp van PHP dus dan is dat geen optie.

Waarom niet?

code:

<script src="bla.php">

Zo kun je ook je externe .js files met behulp van php genereren.

[Cavorka]

André schreef op 28 mei 2004 @ 14:10:
[...]
Waarom niet?

code:

<script src="bla.php">

Zo kun je ook je externe .js files met behulp van php genereren.

Wow, daar heb ik echt nog nooit aan gedacht. Slim!

[André]

Cavorka schreef op 28 mei 2004 @ 14:13:
[...]

Wow, daar heb ik echt nog nooit aan gedacht. Slim!

Zo slim vond ik het niet

[Cavorka]

Mja, ik zit nog een beetje vastgeroest met het idee dat dingen als CSS en JS files altijd statisch zijn, en dus ik als ik wat dynamisch wil maken het 1 groot bestand word (met CSS, JS en XHTML in 1ipv de methode die jij beschrijft.

[ Voor 3% gewijzigd door Cavorka op 28-05-2004 14:20 ]

[Verwijderd]

André schreef op 28 mei 2004 @ 13:53:
[...]

Dus als inline js niet gevalideerd wordt zetten we het maar extern, dat vind ik echt de grootste onzin, je houdt jezelf dan voor de gek met je validatie.

Je begrijpt me niet; ik bedoelde: waarom zou je je JS uberhaupt niet extern willen zetten?

[André]

Verwijderd schreef op 28 mei 2004 @ 14:32:
[...]

Je begrijpt me niet; ik bedoelde: waarom zou je je JS uberhaupt niet extern willen zetten?

Aha, oke

[crisp]

wat mij opvalt is dat je je title als GET parameter mee wil geven, maar er tevens spaties in die title staan. Sowieso verdient het aanbeveling die in elk geval te url-encoden. Dat kan bijvoorbeeld met de escape() method - hoewel deprecated vind ik die nog steeds erg handig voor dit soort dingen.
Wil niet zeggen dat het je probleem oplost, maar als je het netjes wilt doen zou ik het wel meenemen

[Cavorka]

RM-rf schreef op 28 mei 2004 @ 13:39:

[...]
wat betreft het script, plaats voor de winow.open() een een alert van de waardes die je ook aan de window open wilt doorgeven,
als die ook niet uitgevoerd wordt zit je fout ergens daarvoor al

Late reactie, ik had deze reply helemaal gemist: Helaas ligt daar het probleem niet, aangezien het in andere browsers (IE, Opera) wel werkt zoals het zou moeten werken. De variabelen zijn wel gezet, maar het scheiden door de amp's werkt dus niet.

crisp schreef op 28 mei 2004 @ 19:22:
wat mij opvalt is dat je je title als GET parameter mee wil geven, maar er tevens spaties in die title staan. Sowieso verdient het aanbeveling die in elk geval te url-encoden. Dat kan bijvoorbeeld met de escape() method - hoewel deprecated vind ik die nog steeds erg handig voor dit soort dingen.
Wil niet zeggen dat het je probleem oplost, maar als je het netjes wilt doen zou ik het wel meenemen

Will do.

[ Voor 4% gewijzigd door Cavorka op 28-05-2004 20:50 ]

[Verwijderd]

Ik heb het even getest met The Proxomitron. Dit zijn de headers die verstuurd worden met FireFox.

code:

*** Log Reset ***

+++GET 119+++
GET /popup.php?nr=2&path=alfaromeo&title=Alfa%20Romeo%20Monza%208C%202300&g=Cars&s=39&w=1072 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Referer: http://localhost/foo.htm
Connection: keep-alive

+++RESP 119+++
HTTP/1.1 200 OK
Date: Thu, 26 Aug 2004 09:08:34 GMT
Server: Apache/2.0.49 (Win32)
X-Powered-By: PHP/4.3.5
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1
+++CLOSE 119+++

Merk op dat het & niet vervangen wordt voor &. Ik weet niet of dat een vereiste is. Als & opzich ook correct is, dan moet je je vinger richting de makers van PHP wijzen.

Zo ziet de array $_GET eruit:

code:

Array
(
    [nr] => 2
    [amp;path] => alfaromeo
    [amp;title] => Alfa Romeo Monza 8C 2300
    [amp;g] => Cars
    [amp;s] => 39
    [amp;w] => 1072
)

[crisp]

Nee, het ligt niet aan PHP maar aan Mozilla/Firefox.
Dit is wel een mogelijke workaround:

JavaScript:

  var amp = String.fromCharCode(38);
  var url='test.html?piep=poe'+amp+'bloe=bla';
  window.location.href=url;

[Verwijderd]

In principe doet PHP dat prima. De request die javasscript doet is 'verkeerd'. technisch gezien mag het allemaal, maar het doet iets anders dan je eigenlijk wilt. De PHP code doet gewoon wat ervan verwacht wordt.

Denk eraan: die entities zijn om te zorgen dat je javascript gewoon in het document mag staan. De interpreter zou de code moeten krijgen zónder deze entities, dus zeg maar de echte waarde. Niet alle browsers doen dit even goed.

Een simpel voorbeeld:

HTML:

<script type="text/javascript">
   alert('&amp;');
</script>

Ik durf alleen best te beweren dat de parsers vaak niet eens tussen <script> en </script> in kijken. Ze voeren dat vrijwel direct aan de javascript interpreter. (Er wordt vaak alleen wat rare kunstgrepen uitgehaald met commentaar tags.)

HTML:

<body onload="alert('&amp;');">

Dit werkt meestal stukken beter.

Ok, we weten dus dat browsers script blokken over het algemeen verkeerd behandelen. Probeer ze dan ook gewoon te vermijden. En als dat niet in zijn geheel kan doordat er wat variabelen dynamisch moeten worden geset, probeer dan alléén dat dynamische stukje in een document te zetten, en alle statische code in losse javascript files. Zo te zien gaat het in dit geval om een functie, en die code hoort niet te worden veranderd als er ergens en variabele anders is, dus kun je deze functies gewoon in een extern bestand plaatsen.

Als je dit dan ziet als een workaround voor validatie, dan zie je dat wat mij betreft fout. Dit had je sowieso al moeten doen omdat het beter onderhoudbaar is. Bovendien wordt de javascript wellicht gecached. Er zijn meer voordelen dan nadelen.

Er hoort zo weinig mogelijk non-HTML in een HTML document. Vermijd het gebruik van script en style blokken als het kan.

Weet niet of het nog nodig is om het te zeggen, maar in een los Javascript bestand hoeft er natuurlijk geen &amp; te staan als je ergens een ampersand wilt gebruiken.

[ Voor 4% gewijzigd door Verwijderd op 29-05-2004 11:42 ]

[crisp]

Verwijderd schreef op 29 mei 2004 @ 11:41:
[...]Weet niet of het nog nodig is om het te zeggen, maar in een los Javascript bestand hoeft er natuurlijk geen & te staan als je ergens een ampersand wilt gebruiken.

en naar mijn mening zou dat zelfs in een script-blok in het document niet hoeven; de validator zou die blokken gewoon moeten negeren.

[ Voor 3% gewijzigd door crisp op 29-05-2004 11:47 ]

[Verwijderd]

crisp schreef op 29 mei 2004 @ 11:47:

en naar mijn mening zou dat zelfs in een script-blok in het document niet hoeven; de validator zou die blokken gewoon moeten negeren.

Nou, nee. Het hele document is een HTML document. Dat heb je ongetwijfeld al aan de user agent verteld met een DTD. Voor een HTML document zijn er regels. En daar moet je je gewoon aan houden.

Ik ben wel van mening dat een editor tussen script tags de uiteindelijke waarde moet laten zien. Als je dus & tikt tussen script tags, zou bij het opslaan er &amp; van gemaakt kunnen worden. Maar dan is er weer een stukje extra uitleg nodig voor gebruikers van die editor.

edit:
Bovendien doen de browsers het dan nog niet allemaal goed

HTML documenten horen in elk geval volledig door een HTML parser gehaald moeten kunnen worden zonder dat hij choket op een < (wat een &lt; had moeten zijn) of iets dergelijks.

[ Voor 8% gewijzigd door Verwijderd op 29-05-2004 11:55 ]