Is het mogelijk IE gedrag target="_blank" aan te passen?

[Kain_niaK]

Hoi iedereen die dit even leest om mij eventueel te helpen of in de juiste richting te sturen.

Een van onze kleine bedrijfjes is een digital signage bedrijf. Je weet wel, reclame schermen aansturen via een centrale server zodat klanten via de website zelf hun eigen reclame scherm kunnen beheren en de content die de schermen moeten laten zien zelf in elkaar kunnen steken via de website.

Wij gebruiken daar thirdparty software voor want we hebben geen eigen programmeurs en kunnen zelf ook niet programmeren.

Deze software is niet de beste software ter wereld maar is redelijk betrouwbaar en in het algemeen "it gets the job done"

Enfin, de server software draait op linux. Geen problemen daar, maar de windows client software op de reclame schermen is niet meer dat wat veredelde scripting. Op de achtergrond word alles door IE gerendert of door directshow. (en flash en powerpoint en wat dan ook)

Dus na deze inleiding even snel naar het probleem zelf.

We hebben een kiosk samengesteld (sonicview EP4646, maar ik noem het een black monolith) voor een van onze klanten met een groot touchscreen in portrait mode. Zie er allemaal netjes uit en werkt met een virtueel toetsenbord vrij goed. Allemaal onder windows 7 embedded. Ja ik weet het, een kleine custom linux distru zou dit allemaal veel beter kunnen. Maar we hebben te weinig verstand van linux om dat voor elkaar te krijgen.

In ieder geval de functie van deze kiosk is dat mensen naar werk kunnen zoeken en dus ook websites kunnen openen die hun daarin helpen.

Alles werkt alleen er zijn een paar website die html links hebben met target="_blank" erin en die worden dus in een nieuwe tab of pagina geopend en dat willen we dus niet want dan werkt het niet.

Mijn vraag is dus of er een manier is zodat iexplore.exe (dus niet iexplore zelf want die word volgens mij niet geopend) target="_blank" volledig te negeren zodat elke link waarom geklikt word in dezelfde window word geopend. (dus ook geen nieuwe tab). Er is in de layout dus een venster waarin webpagina's te zien en wanneer daar op links geklikt worden moeten die dus openen ook als IE op de achtergrond denkt dat hij die in een nieuwe windows of tab moet openen want dan zijn ze dus niet te zien.


Wat heb ik zelf al geprobeerd? Helemaal niks behalve een halve dag veruchteloos zoeken op google want ik wil eerst weten in welke richting ik moet zoeken. Aanpassing in het registry? Plugin in IE die altijd word geactiveerd op welke manier iexplore ook word geopend?

De website zelf aanpassen door een laag tussen internet en onze signage applicatie te stoppen die eerst alle html filtert en alle target="_blank" verwijdert?

Thx voor de hulp!

[ Voor 10% gewijzigd door Kain_niaK op 11-07-2014 17:26 ]

[RobIII]

Greasemonkey (-alike / IE-compatible) is 't eerste wat me te binnen schiet. Bij pageload gewoon alle links aflopen en overal waar een target attribuut aan hangt het attribuut eraf slopen. Iets in die richting. Maar dan zul je toch écht moeten gaan scripten.

[Kain_niaK]

Okay dat is een beginnetje. Wat ik ook ga doen is onze third party software jongens vragen om hun software een kleine beetje aan te passen omgewoon chrome in een klein venstertje te openen ipv IE. Denk dat het dan vrij eenvoudig te fixen is met de about config opties die chrome je geeft.

Doen ze het niet dan zal ik met de scripting plugins die er voor IE zijn aan de slag moeten.

Eventueel kan ik ook zelf zien of ik hun software een beetje voor de gek kan houden zodat het toch chrome opent ipv IE.

Bedankt voor de reactie Roblll!

[ Voor 6% gewijzigd door Kain_niaK op 11-07-2014 18:50 ]

[MrMonkE]

Ik zou gewoon een jquery javascriptje maken dat alle links de target reset.
Zo iets:

code:

$('a[target="_blank"]').each(function(){   $(this).removeAttr('target');});

Je moet deze dan onload laten triggeren.
En je moet een jquery library includen in je pagina.

Je zou het ook in puur javascript kunnen maken, dan heb je jquery niet nodig maar dat is meer werk.
_{Als het alleen een bepaalde versie IE hoeft te doen valt dat wel mee misschien}

[ Voor 25% gewijzigd door MrMonkE op 11-07-2014 18:57 ]

[Kain_niaK]

We kunnen de pagina niet aanpassen tenzij ik een systeem op zet waar het eens per dag een lokale copy van de website aanmaakt en die aanpast en dan eens per dag refrest en opnieuw aanpast. Maar dat is nogal heel erg veel werk. Het is namelijk een website die ook gewoon door elke werkzoekende in Canada bezocht word door alle mogelijke apparaten.

Uiteraard zou ik wel een tweede pagina kunnen maken die lokaal geopend word en via javascript invloed op de externe website heeft. Is dat wat je bedoeld?

[MrMonkE]

Ja dat bedoel ik. Maar ook daar geld het probleem dat je zult problemen houden met sites die menu's gebruiken in flash of silverlight of dynamisch urls bakken. Het wordt altijd een houtje touwtje oplossing.

Apropos wat jij wil kan wel in chrome en firefox volgens mij maar dat wist je inmiddels waarschijnlijk al.

De beste oplossing is denk ik een proxy gebruiken die overal _blank in _self aanpast.

En anders een IE plugin schrijven.
Het zal niet een super ingewikkelde plugin zijn maar er komt wel development aan te pas.

[ThinkPad]

Moet het perse met IE?
Anders kun je alsnog de oplossing van MrMonkE gebruiken door Firefox/Chrome te gebruiken met een plugin zoals 'Greasemonkey'. Dan kan je websites anders renderen zonder het origineel te hoeven bewerken.

[azerty]

Kun je niet gewoon je chrome.exe hernoemen naar iexplore.exe? of denk ik nu veel te simpel?

[MrMonkE]

ThinkPadd schreef op vrijdag 11 juli 2014 @ 20:29:
Moet het perse met IE?
Anders kun je alsnog de oplossing van MrMonkE gebruiken door Firefox/Chrome te gebruiken met een plugin zoals 'Greasemonkey'. Dan kan je websites anders renderen zonder het origineel te hoeven bewerken.

Er zijn zelfs plugins of setting voor Firefox en Chrome die _blank links naar _self laten gaan.

Er zijn hele volksstammen die fel gekant tegen _blank zijn. lol.


Kweenie, denk dat ze IE browser control geintegreerd hebben in een exe.
Kun je ook prachtig dom veranderen en JS injecten maar allemaal weer extra programmeerwerk.

[ Voor 14% gewijzigd door MrMonkE op 11-07-2014 20:35 ]

[leuk_he]

Kun je niks met de catagorie popup blockers? https://www.google.nl/sea...+add-ons+plugins&safe=off

[Verwijderd]

Waarom geen Chrome? Opensource volledige controle erover of een CEF Chrome Embedded Framework.
Wel grappig dat zo'n professioneel bedrijf IE daarvoor gebruikt met wat scriptjes. lol
Of denk aan je eigen Kiosk portal maken op basis van Node-Webkit draaiende op Linux(werkt ook op windows / osx). Deamon op de achtergrond. Je kan in de config van Node-Webkit ook veel instellen. Popups deactiveren en dergelijke..
Fullscreen is een makkie en ga zo maar door.

Zo kan je gewoon een client draaien op een raspberry pi van 30 dollar zonder dat je een dure volledige X86 PC nodig heb om een crap IE browser te laten draaien. Er zijn verder ook wel andere embedded ARM client hardware te verkrijgen met industriele specs natuurlijk. Velen malen goedkoper dan complete x86 computers.

Voor een directe oplossing zul je toch een plugin denk ik gebruiken waarmee je kan scripten om bij elke "click" action te checken of er een blank voorkomt zoals eerder is voorgesteld.
Als je de link wel wilt openen maar dan niet in een tab of popup dan moet je juist _blank zoeken en vervangen met _self. Zo'n script werkt alleen met HTML atributes. Niet met externe systemen zoals flash enz.

[ Voor 40% gewijzigd door Verwijderd op 13-07-2014 11:50 ]

[RobIII]

Verwijderd schreef op zondag 13 juli 2014 @ 11:36:
Wel grappig dat zo'n professioneel bedrijf IE daarvoor gebruikt met wat scriptjes. lol

En wie ben jij om te beoordelen of een bedrijf dat IE gebruikt wel of niet professioneel is? "lol". Je loopt overal maar MS te bekritiseren en Linux te promoten; wat jij vindt en doet moet je lekker helemaal zelf weten maar je kraamt onzin eerste klas uit; IE is tegenwoordig helemaal niet wat 't vroeger was (en zelfs IE6 was z'n tijd, bij release, vér vooruit t.o.v. andere browsers indertijd) en misschien moet jij eens even je kop uit 't zand trekken. Ja, IE heeft zeker z'n nukken (toen en nu) en ja, er zijn hordes bedrijven veel te lang vast blijven steken op een oude versie wegens lock-ins van hun webapplicaties die niet met nieuwere versies overweg konden en ja, er is heel veel aan te merken op IE (toen én nu) én op MS. Maar als je denkt dat een bedrijf dat z'n hele hebben-en-houwen op standaard PC's. MS en IE heeft gebouwd (en daar klaarblijkelijk goed zaken mee doet) zomaar effe switcht naar Raspberry Pi's, Linux, ARM en whatever omdat ze op één klein drempeltje stuiten moet je denk ik even wakker geschud worden of even wat realiteitszin toegediend krijgen. Je hebt, op basis van TS, amper genoeg informatie om iets te weten van 't bedrijf en je "advies" slaat dan ook als een tang op een varken als je de rest van die informatie niet hebt. Maar het woordje Microsoft werkt klaarblijkelijk een beetje als een rode lap op een stier bij jou.

[ Voor 18% gewijzigd door RobIII op 13-07-2014 14:51 ]

[Kain_niaK]

Verwijderd schreef op zondag 13 juli 2014 @ 11:36:
Waarom geen Chrome? Opensource volledige controle erover of een CEF Chrome Embedded Framework.
Wel grappig dat zo'n professioneel bedrijf IE daarvoor gebruikt met wat scriptjes. lol
Of denk aan je eigen Kiosk portal maken op basis van Node-Webkit draaiende op Linux(werkt ook op windows / osx). Deamon op de achtergrond. Je kan in de config van Node-Webkit ook veel instellen. Popups deactiveren en dergelijke..
Fullscreen is een makkie en ga zo maar door.

Zo kan je gewoon een client draaien op een raspberry pi van 30 dollar zonder dat je een dure volledige X86 PC nodig heb om een crap IE browser te laten draaien. Er zijn verder ook wel andere embedded ARM client hardware te verkrijgen met industriele specs natuurlijk. Velen malen goedkoper dan complete x86 computers.

Voor een directe oplossing zul je toch een plugin denk ik gebruiken waarmee je kan scripten om bij elke "click" action te checken of er een blank voorkomt zoals eerder is voorgesteld.
Als je de link wel wilt openen maar dan niet in een tab of popup dan moet je juist _blank zoeken en vervangen met _self. Zo'n script werkt alleen met HTML atributes. Niet met externe systemen zoals flash enz.

*snip* werving */snip*

edit: geen grap, ik ben bloed serieus.

Hier is de reden dat een overschakeling naar linux op de client side niet zo gemakkelijk is:

Het bedrijf waar wij de software van gebruiken heeft een linux client die op ubuntu 12.04 draait.

Nu heb je kleine winkels die een goedkoop reclame scherm willen. Kunnen wij mee helpen. Ik ben goed met de technische kant en mijn baas is goed met mensen (want geen nerd).

Nu heeft deze klant geen geld om dure grafische ontwikkelaars te huren en wij besteden dat soort werk meestal uit tenzij het echt super basic is met een PGN layout te maken in Photoshop en verder wat tekst.

Gelukkig is er een oplossing .De windows client ondersteunt namelijk practisch elk windows format. Van powerpoint tot ms word tot wat dan ook.

En dus kunnen klanten zelf een powerpoint in elkaar steken en zelf uploaden naar ons website portal waar ze een account hebben. Helaas is het allemaal een stuk lastiger om dat allemaal aan de praat te krijgen op linux tenzij je een linux guru bent. Flash dat smooth draait op linux out of the box? Niet zo maar op elke grafische kaart. Ik kan het wel voor elkaar krijgen maar alleen als ik een paar dagen vrij neem van werk om weer wat meer over linux te leren. Die luxe heb ik niet.

Rasberry Pi als digital signage computer? Goed idee -->

http://elinux.org/RPi_Projects/Digital_Signage
http://www.edugeek.net/fo...raspberry-pi-ideas-4.html
http://www.raspberrypione...environmental-monitoring/
http://www.raspberrypi.or...c.php?f=41&t=924&start=25
YouTube: Digital signage using Xibo
http://www.dailydooh.com/archives/36778
productreview: Raspberry Pi model B (512MB) review door AldoGMB

*snip* werving */snip*

Het meest compatible zou zijn als de server alles eerst converteert naar H264 video voor het naar de players gaan. Die hoeven dan alleen maar videobestanden te downloaden en te laten zien. Een raspberry pi is hier geschikt voor en kan in principe veel minder complex zijn dan een volledige windows dekstop computer.

Als we zoiets voor elkaar krijgen dan maken we meer winst, kunnen meer automatiseren. Kunnen onze players voor nog scherpe prijzen aanbieden en kunnen we waarschijnlijk in ieder geval in Alberta alle andere concurrenten binnen een paar jaar van de markt duwen.

*snip* werving */snip* En het feit dat er momenteel ontelbaar startups met exact hetzelfde bezig zijn. Sommige zijn er al half klaar mee en bieden al een hele goede dienst aan. Gelukkig zijn al die bedrijfjes dus niet zo goed met persoonlijke relaties met klanten want allemaal internet based. Hier in het conservatieve Canada heeft men liever een betrouwbaar gezicht. Dat heeft mijn baas dus en vandaar dat we zo'n 500 klanten hebben waaronder The City of Calgary.
Ook al geven onze windows based players ons gigantisch veel problemen want windows en hardware configuraties die te complex zijn voor een 24/24 online player die nooit rebooten. Also, ik ben ook niet de slimste wanneer het op automatiseren aan komt ... en het blijft ook lastig als je 20 verschillende hardware configuraties hebt met systemen die nog op XP draaien tot en met windows 7 embedden. Soms heeft de klant een goed idee en de klant is koning ... dus.


Enfin, vergeef me deze rant. *snip* werving */snip*

[ Voor 74% gewijzigd door RobIII op 14-07-2014 22:17 ]

[R4gnax]

Okee. Vooropgesteld; dit gaat even heel hard klinken. Excuses vooraf voor de gevoeliger medepersoon.

Je werkt bij een bedrijf in de automatisering/ IT (digital signage), je klantportfolio bevat in de orde van grootte van 500 klanten, waaronder een paar flinke en prominente jongens die niet zomaar met iedereen in zee zullen gaan. Maar ondertussen is er bij dit bedrijf nagenoeg nul technische kennis aanwezig? (Geen inhouse programmeurs, enkel levering via third-party software.)

En nu loop je, met de toegenomen vraag vanuit de klanten tegen technische problemen aan die met de stock software niet te verhelpen zijn en waar technische kennis eigenlijk noodzakelijk is.

Het klinkt eigenlijk alsof je werkgever te lang op het scherpst van de snede heeft gezeten met de inkomsten/uitgaven, misschien mede door onder de prijs te verkopen, en het niet heeft kunnen of willen permiteren om tijdens de groei van het bedrijf en de klantencirkel ook de technische expertise de werknemers mee te laten groeien. Tot op zekere hoogte kun je het dan met een vriendelijk gezicht en een vlotte babbel nog bolwerken, ja. Maar uiteindelijk val je door de mand en dan pluk je daar de zure vruchten van.

Vanuit een breder punt gezien zou mijn advies zijn om werk te maken van het in dienst nemen van in-house technisch bekwaam personeel, wat kan assisteren met klant-gerichte customization, en wat, als de huidige software pakketen daarin niet meegevend genoeg zijn, kan helpen met de selectie of uitwerking van alternatieven.


Wat betreft je concrete vraag over het voorkomen dat webpagina's nieuwe tabs of vensters gaan openen: vergeet dat maar heel snel. Dat ga je niet even simpel voorkomen met een scriptje.

target='_blank' is niet de enige manier om een nieuw venster geopend te krijgen. target='foo' opent bijvoorbeeld ook deftig een nieuw venster als er nog geen venster met de naam 'foo' bestaat. En dat wordt nog best wel eens gebruikt bij websites die functionele popup vensters maar één keer willen openen en daarna over de hele site heen willen 'delen'.

Daarnaast heb je ook altijd nog window.open, wat op ik weet niet hoeveel verschillende manieren ergens aangeroepen kan worden. En je hebt IE's speciale smaakjes om modal dialogs te openen.

Het is sinds de opkomst van in-window JavaScript overlay vensters allemaal niet zo heel erg populair meer, maar je kunt er donder op zeggen dat oude aftandse semi-overheidsrommel er nog steeds gebruik van maakt. (Als jouw software dat dan stuk maakt, mag je één keer raden wiens probleem het wordt om het op te lossen. ... Juist ja.)

Veel beter om te werken aan het opzetten van een centrale databank waarin vacatures ondergebracht kunnen worden, het evt. aangaan van contracten met leveranciers hiervoor en het opzetten van een degelijke integrale oplossing. (Touch geoptimaliseerd, zodat gebruikers ook niet halverwege stranden op gammele :hover afhankelijke implementaties, om maar eens iets te noemen...).

[ Voor 10% gewijzigd door R4gnax op 14-07-2014 20:48 ]

[SinergyX]

Zijn opzich tabs een probleem? Kiosk mode bv van Windows 8 in metro mode kan enkel tabs openen, nooit nieuwe 'windows', plus dat het ook erg touch vriendelijk is.

[Kain_niaK]

R4gnax schreef op maandag 14 juli 2014 @ 20:42:
Okee. Vooropgesteld; dit gaat even heel hard klinken. Excuses vooraf voor de gevoeliger medepersoon.

Je werkt bij een bedrijf in de automatisering/ IT (digital signage), je klantportfolio bevat in de orde van grootte van 500 klanten, waaronder een paar flinke en prominente jongens die niet zomaar met iedereen in zee zullen gaan. Maar ondertussen is er bij dit bedrijf nagenoeg nul technische kennis aanwezig? (Geen inhouse programmeurs, enkel levering via third-party software.)

En nu loop je, met de toegenomen vraag vanuit de klanten tegen technische problemen aan die met de stock software niet te verhelpen zijn en waar technische kennis eigenlijk noodzakelijk is.

Het klinkt eigenlijk alsof je werkgever te lang op het scherpst van de snede heeft gezeten met de inkomsten/uitgaven, misschien mede door onder de prijs te verkopen, en het niet heeft kunnen of willen permiteren om tijdens de groei van het bedrijf en de klantencirkel ook de technische expertise de werknemers mee te laten groeien. Tot op zekere hoogte kun je het dan met een vriendelijk gezicht en een vlotte babbel nog bolwerken, ja. Maar uiteindelijk val je door de mand en dan pluk je daar de zure vruchten van.

Vanuit een breder punt gezien zou mijn advies zijn om werk te maken van het in dienst nemen van in-house technisch bekwaam personeel, wat kan assisteren met klant-gerichte customization, en wat, als de huidige software pakketen daarin niet meegevend genoeg zijn, kan helpen met de selectie of uitwerking van alternatieven.


Wat betreft je concrete vraag over het voorkomen dat webpagina's nieuwe tabs of vensters gaan openen: vergeet dat maar heel snel. Dat ga je niet even simpel voorkomen met een scriptje.

target='_blank' is niet de enige manier om een nieuw venster geopend te krijgen. target='foo' opent bijvoorbeeld ook deftig een nieuw venster als er nog geen venster met de naam 'foo' bestaat. En dat wordt nog best wel eens gebruikt bij websites die functionele popup vensters maar één keer willen openen en daarna over de hele site heen willen 'delen'.

Daarnaast heb je ook altijd nog window.open, wat op ik weet niet hoeveel verschillende manieren ergens aangeroepen kan worden. En je hebt IE's speciale smaakjes om modal dialogs te openen.

Het is sinds de opkomst van in-window JavaScript overlay vensters allemaal niet zo heel erg populair meer, maar je kunt er donder op zeggen dat oude aftandse semi-overheidsrommel er nog steeds gebruik van maakt. (Als jouw software dat dan stuk maakt, mag je één keer raden wiens probleem het wordt om het op te lossen. ... Juist ja.)

Veel beter om te werken aan het opzetten van een centrale databank waarin vacatures ondergebracht kunnen worden, het evt. aangaan van contracten met leveranciers hiervoor en het opzetten van een degelijke integrale oplossing. (Touch geoptimaliseerd, zodat gebruikers ook niet halverwege stranden op gammele :hover afhankelijke implementaties, om maar eens iets te noemen...).

Ik noem hem mijn baas maar we zijn partners. Voordat ik de technische kant van het bedrijf overnam deed hij het allemaal zelf. Da's dus twee man in het hele bedrijf. Hij is al 7 jaar bezig en ik ben er twee jaar geleden bij gekomen. Hij had al 400 klanten, nu heeft hij er 500. De meeste zijn vrij klein maar er zitten inderdaad wat grotere klanten tussen. Dus we doen in ieder geval iets goed. Aan mij de taak om verder te snoeien in de verschillende configuraties zodat er minder fout kan gaan. Om bijvoorbeeld DXVA ook aan de praat te krijgen op atom systemen die zonder hardware acceleratie geen 1080p en hoger kunnen afspelen zonder schokken. Af en toe lastig als klanten AVI's van de jaren stilletjes uploaden naar de server.

Etc etc. Ik ben geen programmeur en hij is geen programmeur maar dat hoeft ook niet. De server software en de client software komt van een Amerikaans bedrijf. We betalen hun maandelijks een klein fortuin en eigenlijk zou hun support een stuk beter moeten zijn. In ieder geval hun systeem werkt ook al is het niet perfect. Het werkt en zelfs klanten die absoluut geen kaas van computers hebben gegeten krijgen het voor elkaar om ads in elkaar te steken op de portaal website en rechtstreeks hun players te beheren. Da's ook een kunst.

Ik kan die software jongens dus welk vragen: Hey kerels verander die client side software nu eens heel eventjes zodat het ook chrome geopend krijgt in de layout en niet alleen IE. Als ze dan blijven herhalen dat het niet kan ga je toch zelf een beetje op zoek. En nee, we kunnen ze niet aan de kant schuiven tot we zelf programmeurs hebben en een eigen platform. Maar da's dus helemaal niet zou eenvoudig als het lijkt.

Die software jongens hebben denk ik wel een paar honderd duizend klanten wereldwijd. Die hebben het OOK druk.

[gitaarwerk]

Klopt, het is lastig om goede programmeurs te krijgen tegen een ook nog voor de werkgever goed salaris. Zeker als je weinig kennis hebt is het soms moeilijk te beoordelen. Het is waar dat je met externe partijen vaak niet altijd goed af bent.

Laat ik even noemen een PSP waar ik de naam niet van ga noemen. Die softare is zwaar verouderd, slechte front-end code, trage verbindingen, eenmaal per half jaar een release, en oh ja, die zitten voor de komende twee jaar vol. Dus succes daar wat aan te gaan veranderen.

Nu zijn we gelukkig een hele grote klant van hun, want ja, we doen bijna 3000 transacties bij ze per dag. Dus dat was het dan... fix het, of we stappen over. Nu hebben we wel gelukkig een stok achter de deur... maar helaas ben je altijd wel afhankelijk van dit soort partijen. De reden waarom is ook gewoon heel simpel door boeteclausules, beveiliging, verantwoordelijkheid etc etc.. We kunnen dit wel gaan doen, zelfde als logistiek doen, maar dan bevind je jezelf al heel snel in een ander vaarwater. Vraag is of je dat wel wilt.


Afijn.. on topic.. Je kan inderdaad het beste wellicht een proxy gebruiken. Dat is even in de materie duiken, maar als je een beetje pienter ben (en dat ben je vast wel, want je zit op tweakers ) zou dat de beste oplossing zijn. En eigenlijk wil je de meeste "targets" er wel afslopen. Uiteindelijk kun je zeker niet alles afvangen. MAar dat is het meest centrale. Die regels zijn ook makkelijker uit te rollen dan een greasemonkey script, alhoewel dat dat ook goed zou werken.


Zo zijn er nog wel wat oplossingen, maar die worden ingewikkelder.

In ieder geval, je hoeft geen programmeur te zijn,.. het is niet eng


Edit: Misschien een hele stomme opmerking (ik heb geen IE bij de hand, dus kan niet testen)... maarrehm... Kun je niet in IE settings zetten dat je niet in een nieuw venster iets mag openen??

[ Voor 5% gewijzigd door gitaarwerk op 15-07-2014 22:02 ]

[Kain_niaK]

Die settings heeft IE dus niet ook niet in het register. Chrome en Firefox wel. Is misschien de reden dat zoveel developers een hekel aan die target=_blank hebben.

[RobIII]

Kain_niaK schreef op dinsdag 15 juli 2014 @ 22:27:
Is misschien de reden dat zoveel developers een hekel aan die target=_blank hebben.

Nee; de reden waarom zoveel developers (maar waarschijnlijk(er): mensen met (al dan niet naar eigen zeggen) verstand van UX) daar een hekel aan hebben is "omdat mensen zelf prima in staat zijn te besluiten wanneer ze een nieuw venster willen of de huidige tab willen gebruiken. Je kunt al sinds jaar-en-dag een 'muiswilklik' gebruiken om een nieuwe tab te openen voor een link (althans: dat is 'default behaviour') en dat hoeft een-of-andere-sitebouwer niet voor mij te bepalen". Daarbij was 't onder XHTML deprecated en dan "valideerde" je XHTML niet meer en dan kon je natuurlijk niet zo'n hippe "XHTML valid" badge op je site zetten

(Overigens: de meningen over wel/niet target="_blank" gebruiken zijn nogal verdeeld; maar als je 't hebt over "developers [die] een hekel aan die target=_blank hebben" dan heb je 't dus over het kamp dat daar over klaagt )

[ Voor 39% gewijzigd door RobIII op 15-07-2014 23:36 ]

[MrMonkE]

RobIII schreef op dinsdag 15 juli 2014 @ 23:26:
Je kunt al sinds jaar-en-dag een 'muiswilklik' gebruiken om een nieuwe tab te openen voor een link (althans: dat is 'default behaviour') en dat hoeft een-of-andere-sitebouwer niet voor mij te bepalen".

Dat weet bijna niemand. Ga maar eens voor een ziekenhuis met 3000 mensen een intranet app maken.
Die mensen kunnen amper een link klikken. Jij bent misschien in de illusie dat iedereen dat weet maar ik maak me sterk dat niet eens 5% dit of shift-click weet.

Ik vind het helemaal niet zo raar als een site links naar andere partijen in een nieuwe browser of tab opent.

[Wim-Bart]

Waarom laat je niet alles door een "proxy" lopen en laat je die dan niet een "content" rewrite doen. Bijvoorbeeld een Citrix Netscaler kan het, beetje dure oplossing, maar er zijn vast wel Linux of windows oplossingen hiervoor.

https://www.google.nl/?gw...0with%20content%20rewrite

[johnkeates]

Als je inderdaad een proxy kan gebruiken zou je het zonder de software aan te passen kunnen doen.
Dit is waarschijnlijk zelfs met Apache of nginx te doen, maar ongetwijfeld met Squid.

[MrMonkE]

Misschien is dit wat (ik heb het zelf niet goed gelezen, ben beetje moe)
http://www.mydigitallife....rdless-of-number-of-tabs/

[.oisyn]

MrMonkE schreef op vrijdag 11 juli 2014 @ 18:55:
Ik zou gewoon een jquery javascriptje maken dat alle links de target reset.
Zo iets:

code:

$('a[target="_blank"]').each(function(){   $(this).removeAttr('target');});

Je houdt van nutteloze complexiteit? Waarom over de lijst van elementen heen lopen met each(), als je ook gewoon removeAttr() op de lijst van elementen kunt doen?

JavaScript:

$('a[target="_blank"]').removeAttr('target');

[ Voor 6% gewijzigd door .oisyn op 16-07-2014 01:17 ]

[MrMonkE]

Schooled.

Eigenlijk wilt ie alle targets weg dus kan nog makkelijker maar het is niet toe te passen zo helaas omdat hij geen script kan injecten.

[ Voor 88% gewijzigd door MrMonkE op 16-07-2014 01:33 ]

[Kain_niaK]

Kan ik twee pagina's tegelijk openen? Een in de background die een lokale html pagina van de harde schijf laad en de tweede pagina is dan de website die bezocht word. Vervolgens kan ik misschien als ik een zooi veiligheidsparameters wijzig met een script op de ene pagina het gedrag van de andere pagina aanpassen?

Maar ondertussen zijn we een tijdje verder en ik heb nog niks uitgeprobeerd. Dus ik ga terug pas reageren als ik wat dingen heb uitgeprobeerd. Het eerste is kijken op de digital signage software ook chrome kan openen ipv IE en hoe het er dan uitziet.

Bedankt voor die link MrMonkE, ziet er intressant uit.

[soulrider]

spijt elf en zoveel meer ... of voor de oudere Belgen: "witte van zichem"-gewijs:

is het niet gewoon mogelijk om een proxy te zetten tussen je IE-kiosk en je server? en die proxy dan alle html met target='_blank' en soortgelijken te laten herschrijven naar target='self' of het te verwijderen ?

hoef je niets te wijzigen op je server, en enkel op je kiosks IE in te stellen om die proxyserver te gebruiken.

bv: privoxy met +filter{unsolicited-popups} of +filter{all-popups}

unsolicited-popups
This filter attempts to prevent only "unsolicited" pop-up windows from opening, yet still allow pop-up windows that the user has explicitly chosen to open. It was added in version 3.0.1, as an improvement over earlier such filters.

Technical note: The filter works by redefining the window.open JavaScript function to a dummy function during the loading and rendering phase of each HTML page access, and restoring the function afterwards.

all-popups
Attempt to prevent all pop-up windows from opening. Note this should be used with more discretion than the above, since it is more likely to break some sites that require pop-ups for normal usage. Use with caution.

en wellicht kan je na wat google-fu wel een config vinden die de specieke code in jullie html die zorgt voor de popup kan herschrijven naar een nog steeds correct werkend iets zonder popups.

ps: helpt onrechtstreeks ook wat je klanten om hun webtrafiek te beperken ;-)

Dat kan eventueel zelfs een proxy zijn die op de windows kiosk zelf draait.
(wat lastiger in onderhoudt wellicht - maar daar kan ev. met een autoit-scriptje dat bv dagelijks of bij opstart draait de config-file van die proxy-server op die kiosk worden afgehaald van je linux-webserver ?
Bij provixy doe je dat bv door alles in een user.action-bestand te zetten en die dus algemeen te maken over die klanten (indien proxy op kiosk draait en niet op een eigen server tusen linux server en IE-client-kiosk)

[ Voor 58% gewijzigd door soulrider op 16-07-2014 06:52 ]

[Tribits]

Ik heb nu een (min of meer) werkende oplossing met een stukje VBScript. Min of meer werkend want er zitten wel wat haken en ogen aan: De browser wordt door het script gestart via een call naar CreateObject. Dat werkt op zich wel maar de browser gedraagt zich dan vaak toch net iets anders dan dat deze normaal gestart wordt. Zo is full screen mode bijvoorbeeld niet af te sluiten. Verder lukt het via VBScript alleen om de browser in een window of full screen te openenen, een maximized window kreeg ik op geen manier voor elkaar (in VBScript).

Tevens kwam ik er niet goed achter op welk event ik de targets het beste kan strippen. Zowel DocumentComplete als NavigateComplete2 lijken een stuk vaker op te treden dan je zou verwachten (dwz 1 keer per pagina). Als lapwerk zet ik dus maar even een attribute op de body tag om snel te kunnen bepalen of de tags al gestript zijn. Het strippen zelf doe ik nu met behulp van een stukje javascript dat ik na het laden in de pagina inject. Het is op zich ook wel mogelijk om de tags vanuit VBScript te strippen maar ik had het vermoeden dat dit iets sneller is.

Ook zijn de eerder genoemde bezwaren natuurlijk nog van toepassing. Dit vangt alleen target="_blank" attributes af die bij het laden van de pagina al aanwezig zijn. Ik weet dus niet hoe dit zich gedraagt op pagina's die (veel) gebruik maken van Ajax. Mogelijk is er een event dat wel/beter geschikt is om de code te updaten na een Ajax call. Enfin, mocht je ondanks dit alles nog niet afgehaakt zijn dan hier de code:

VBScript:

Dim Browser
Dim MustQuit
Const HomePage="www.tweakers.net"

Public Sub StartBrowser()
  MustQuit = False
  Set Browser = WScript.CreateObject("InternetExplorer.Application","Browser_")

  Set WshShell = CreateObject("WScript.Shell")

  Browser.visible = true
  WshShell.AppActivate "Internet Explorer"
  Browser.FullScreen=true
  
  Browser.Navigate2 HomePage
  
  While Not MustQuit
    WScript.sleep 1000
  Wend
End Sub

Sub Browser_DocumentComplete(ByVal pDisp, URL)
  WScript.echo "DocumentComplete"
  Set Body = Browser.Document.getElementsByTagName("Body").item(0)
  If IsNull(Body.GetAttribute("data-anchortarget")) Then
    Set item = Browser.Document.createElement("Script")
    item.innerHTML = "var anchors = document.getElementsByTagName('A'); for(var i = 0; i < anchors.length; i++){ var anchor=anchors[i]; if(anchor.target=='_blank') anchor.removeAttribute('target'); }"
    Body.appendChild item
    Body.SetAttribute "data-anchortarget","done"
  End If
End Sub

Sub Browser_OnQuit()
  WScript.echo "OnQuit" 
  MustQuit = True
End Sub

StartBrowser

In elkaar gefreubeld en getest onder Win7 Pro x64 met IE11.

[RobIII]

edit:

*snip* hier stond onzin

Tribits schreef op vrijdag 18 juli 2014 @ 23:17:

VBScript:

    item.innerHTML = "var anchors = document.getElementsByTagName('A'); for(var i = 0; i < anchors.length; i++){ var anchor=anchors[i]; if(anchor.target=='_blank') anchor.removeAttribute('target'); }"

Targets kunnen ook van toepassing zijn op (o.a.) een Form en image maps (AREA). Ik zou dus gewoon alle elementen aflopen i.p.v. alleen de anchors (getElementsByTagName('A') in je code)); lekker lomp maar trefzekerder

quote: http://www.w3.org/TR/html401/present/frames.html#target-info

The target attribute may be set for elements that create links (A, LINK), image maps (AREA), and forms (FORM).

En dan vang je nog steeds geen JS window.open calls e.d. (die je zou kunnen "overriden"; dat lijkt iig onder Chrome en IE11 goed te gaan (fiddle)) en andere zaken die nieuwe windows openen. Het meeste is denk ik nog best goed te doen maar bij Flash etc. ga je toch echt in de problemen komen denk ik.

[ Voor 45% gewijzigd door RobIII op 18-07-2014 23:43 ]

[Alex)]

Deze oplossing is niet echt waterdicht. Ik zie sowieso al een paar tekortkomingen:

1) Je houdt geen rekening met frames en iframes, die ook links met target="_blank" kunenn bevatten
2) Als je je script gaat aanpassen om wel rekening te houden met (i)frames zul je ongetwijfeld websites tegenkomen die stuk gaan omdat ze een target hebben die naar een ander (i)frame verwijst.
3) Er zijn ook links die kunnen worden geopend vanuit scripts, flash-objecten, enzovoorts. Dat vang je hiermee niet af.

De enige juiste manier om dit af te handelen is door je te verdiepen in het objectmodel dat IE beschikbaar stelt. Zo is het mogelijk om het nieuw venster-event te onderscheppen, maar hiervoor zal wel wat ontwikkelwerk gedaan moeten worden.

[ Voor 0% gewijzigd door Alex) op 18-07-2014 23:53 . Reden: fyptout ]

[RobIII]

Alex) schreef op vrijdag 18 juli 2014 @ 23:46:
Deze oplossing is niet echt waterdicht. Ik zie sowieso al een paar tekortkomingen:

1) Je houdt geen rekening met frames en iframes, die ook links met _target="blank" kunenn bevatten

blank is een geldige framename, _blank niet Maar daar draait 't topic dan ook precies om; die _blank wil je niet in een nieuw window/tab hebben maar in 't huidige window/tab.

Alex) schreef op vrijdag 18 juli 2014 @ 23:46:
2) Als je je script gaat aanpassen om wel rekening te houden met (i)frames zul je ongetwijfeld websites tegenkomen die stuk gaan omdat ze een target hebben die naar een ander (i)frame verwijst.

Hence mijn edit (ik neem even aan dat je op mijn eerste alinea doelde; die heb ik inderdaad verwijderd omdat ik in eerste instantie dacht dat _top, _parent, _self of _blank allemaal niet zou boeien als je 't zou verwijderen en dus resoluut overal 't target attribuut af kon strippen, maar dat was wat kort-door-de-bocht-gedacht O.a. door inderdaad ook de mogelijkheid tot framenames en je wil sites met frames niet breken idd.)

Alex) schreef op vrijdag 18 juli 2014 @ 23:46:
3) Er zijn ook links die kunnen worden geopend vanuit scripts

Zie mijn (vlug geflanste) "demo'tje". Geen idee welke haken-en-ogen er aan zitten, maar het demonstreert in ieder geval 't basisidee

Alex) schreef op vrijdag 18 juli 2014 @ 23:46:
flash-objecten

Zie mijn post "Het meeste is denk ik nog best goed te doen maar bij Flash etc. ga je toch echt in de problemen komen denk ik."

Alex) schreef op vrijdag 18 juli 2014 @ 23:46:
enzovoorts. Dat vang je hiermee niet af.

Is ook door niemand gezegd dat 't waterdicht was. Maar je vangt er wel al veel mee; niet alles nee. De vraag is of dat afdoende is voor TS of niet.

Alex) schreef op vrijdag 18 juli 2014 @ 23:46:
De enige juiste manier om dit af te handelen is door je te verdiepen in het objectmodel dat IE beschikbaar stelt. Zo is het mogelijk om het nieuw venster-event te onderscheppen, maar hiervoor zal wel wat ontwikkelwerk gedaan moeten worden.

Wat dus betekent dat je zelf een IE "object" gaat hosten; TS wilde niet / weinig ontwikkelen en met een 'greasemonkey' (maar dan voor IE) scriptje en kennis uit voorgaande posts kom je dan al een heel eind me dunkt. Ik zou dat dus eerst eens gaan onderzoeken (a) bestaat zoiets wel voor IE, geen idee namelijk en b) hoe goed werkt dat (voor TS; misschien is Flash niet eens geïnstalleerd of zijn er geen flash componenten op de pagina's aanwezig en dus sowieso al geen probleem om maar wat te noemen)) voordat ik me nog veel dieper in de nesten zou werken en IE ging hosten. Het 'greasemonkey' scriptje is vrijwel zeker een stuk minder ontwikkelwerk; dat is wat ik wil zeggen. Ik sluit niet uit dat je, uiteindelijk, misschien alsnog bij 'IE hosten' uit komt. Ik zou dan nog eerder R4gnax's laatste alinea overwegen.

[ Voor 11% gewijzigd door RobIII op 19-07-2014 00:02 ]

[Alex)]

RobIII schreef op vrijdag 18 juli 2014 @ 23:52:
[...]

blank is een geldige framename, _blank niet Maar daar draait 't topic dan ook precies om; die _blank wil je niet in een nieuw window/tab hebben maar in 't huidige window/tab.

Typfoutje, ik heb het al verbeterd.

Wat dus betekent dat je zelf een IE "object" gaat hosten; TS wilde niet / weinig ontwikkelen en met een 'greasemonkey' (maar dan voor IE) scriptje en kennis uit voorgaande posts kom je dan al een heel eind me dunkt. Ik zou dat dus eerst eens gaan onderzoeken (a) bestaat zoiets wel voor IE, geen idee namelijk en b) hoe goed werkt dat) voordat ik me nog veel dieper in de nesten zou werken en IE ging hosten. Het 'greasemonkey' scriptje is vrijwel zeker een stuk minder ontwikkelwerk; dat is wat ik wil zeggen. Ik sluit niet uit dat je, uiteindelijk, misschien alsnog bij 'IE hosten' uit komt.

Een scriptje gebruiken is een grote-stappen-snel-thuis-oplossing waarbij er volgens mij uiteindelijk meer dingen stuk gaan dan dat ze blijven werken. Zelf IE hosten is even wat uitzoekwerk, maar uiteindelijk bereik je daar wel een veel betere oplossing mee die niet 80% van de gevallen afvangt, maar 100%.

Ik zou dan nog eerder R4gnax's laatste alinea overwegen.

Dat is uiteraard een nog betere oplossing.

[ Voor 5% gewijzigd door Alex) op 19-07-2014 00:05 ]

[RobIII]

Alex) schreef op zaterdag 19 juli 2014 @ 00:02:
Een scriptje gebruiken is een grote-stappen-snel-thuis-oplossing

...waar TS naar op zoek was.

Alex) schreef op zaterdag 19 juli 2014 @ 00:02:
wel een veel betere oplossing mee die niet 80% van de gevallen afvangt, maar 100%.

Die 80% durf ik te betwijfelen (flash daargelaten denk ik dat je veel meer vangt, misschien wel 95-99% als je het goed doet). En misschien is dat voor TS allang afdoende? En ik weet niet wat er op die 'reclame schermen' allemaal gebeurt / toegankelijk is maar misschien zijn de sites helemaal niet zo exotisch en is 't beperkt tot een X-aantal whitelisted domeinen i.p.v. het complete-grote-boze-intarwebs)? IE hosten is misschien geen rocket science maar ook niet in een middagje in mekaar gedraaid (zodat je een fatsoenlijk bruikbaar product hebt uiteraard) waar je wel met een (mid)dagje "greasemonkey scriptjes frobelen" inderdaad al in grote stappen snel thuis bent mogelijkerwijs. Dan probeerde ik dat eerst eens om te kijken hoe dat (in de praktijk) uitwerkt voordat ik verder ging kijken. Maar, ongelimiteerd budget en fatsoenlijke developers tot je beschikking hebbende ben ik 't, uiteraard, met je eens dat je dan gewoon voor jouw methode en "de 100%" moet gaan.

[ Voor 25% gewijzigd door RobIII op 19-07-2014 00:10 ]

[Tribits]

Alex) schreef op vrijdag 18 juli 2014 @ 23:46:
De enige juiste manier om dit af te handelen is door je te verdiepen in het objectmodel dat IE beschikbaar stelt. Zo is het mogelijk om het nieuw venster-event te onderscheppen, maar hiervoor zal wel wat ontwikkelwerk gedaan moeten worden.

Dat is op zich hetzelfde objectmodel als ik hier in VBScript gebruik. Helaas werkt het onderscheppen van NewWindow2/NewWindow3 niet. Ik krijg de events wel binnen maar kan de parameters niet aanpassen, dit ondanks dat ik ze als ByRef heb gedeclareerd. Meer tekortkomingen van VBScript vrees ik.

Ik heb overigens ook nog gezocht naar Greasemonkey achtige solutions voor Windows. Er zijn vrij veel sites die 'Trixie' noemen als IE plugin die de meeste Greasemonkey scripts kan draaien. Helaas is Trixie al sinds 2005 niet meer supported dus ik betwijfel of je daar tegenwoordig nog veel aan hebt. Met wat moeite heb ik een werkende download kunnen vinden maar geen enkele documentatie dus dat maar even gelaten voor wat het was. Min of meer hetzelfde verhaal voor GreasemonkeyIE. Op Stackoverflow raadt iemand Kango extension framework aan. Crossbrowser scripting support maar helaas niet gratis voor commercieel gebruik.

Heb inmiddels een versie in C# die OnNewWindow3 afvangt. Ziet er goed uit, kanttekening is wel dat het maar de vraag is of TS het .Net Framework 4 op zijn Windows 7 (Embedded) heeft draaien. Maar goed, hier de code:

C#:

namespace InternetExplorerCS
{
    using System;
    using SHDocVw;
    using System.Runtime.InteropServices;

    public class Explorer 
    {
        static private SHDocVw.InternetExplorer _internetExplorer = null;
        static private IWebBrowserApp _webBrowser = null;
        private Boolean _gotQuit = false;
        private const int SW_SHOWMAXIMIZED = 3;
        [DllImport("user32.dll")]
        static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);

        public void Run()
        {
            try
            {
                _internetExplorer = new SHDocVw.InternetExplorer();
            }
            catch(Exception e)
            {
                Console.WriteLine("Exception when creating Internet Explorer object {0}", e);
                return;
            }

            SetAllEvents();

            try
            {  
                _webBrowser = _internetExplorer;
                _webBrowser.Visible = true;
                // _webBrowser.FullScreen = true;
                _webBrowser.GoHome();
                ShowWindow((IntPtr) _webBrowser.HWND, SW_SHOWMAXIMIZED);

                while (!_gotQuit)
                    System.Threading.Thread.Sleep(1000);
            }
            catch(Exception sE)
            {
                Console.WriteLine("Exception happens {0}", sE);
            }
        }
        
        void SetAllEvents()
        {
            if (_internetExplorer != null)
            {
                _internetExplorer.NewWindow3 += OnNewWindow3;
                _internetExplorer.OnQuit += OnQuit;
            }
        }

        void OnNewWindow3(ref object ppDisp, ref bool cancel, uint flags, string urlContext, string url)
        {
            cancel = true;
            _internetExplorer.Navigate2(url);
        }

        void OnQuit()
        {
            _gotQuit = true;
        }

        public static void Main()
        {
            var explorer = new Explorer();
            explorer.Run();
        }
    }
}

Nog een belangrijke opmerking: Om dit werkend te krijgen onder .Net 4, moet de property "Embed Interop Type" van "Interop.SHDocVw" op False staan en "Local Copy" op True, anders werken de events niet correct.

[ Voor 78% gewijzigd door Tribits op 20-07-2014 02:08 ]

[Kain_niaK]

RobIII schreef op zaterdag 19 juli 2014 @ 00:07:
[...]

...waar TS naar op zoek was.


[...]

Die 80% durf ik te betwijfelen (flash daargelaten denk ik dat je veel meer vangt, misschien wel 95-99% als je het goed doet). En misschien is dat voor TS allang afdoende? En ik weet niet wat er op die 'reclame schermen' allemaal gebeurt / toegankelijk is maar misschien zijn de sites helemaal niet zo exotisch en is 't beperkt tot een X-aantal whitelisted domeinen i.p.v. het complete-grote-boze-intarwebs)? IE hosten is misschien geen rocket science maar ook niet in een middagje in mekaar gedraaid (zodat je een fatsoenlijk bruikbaar product hebt uiteraard) waar je wel met een (mid)dagje "greasemonkey scriptjes frobelen" inderdaad al in grote stappen snel thuis bent mogelijkerwijs. Dan probeerde ik dat eerst eens om te kijken hoe dat (in de praktijk) uitwerkt voordat ik verder ging kijken. Maar, ongelimiteerd budget en fatsoenlijke developers tot je beschikking hebbende ben ik 't, uiteraard, met je eens dat je dan gewoon voor jouw methode en "de 100%" moet gaan.

Voorlopig is het zo opgelost. We hebben een aantal pagina's statisch gemaakt en gehost op onze eigen server. En dan alle _blank weggehaalt. Kortom, we hebben de frontpage van de jobbank van het internet gepakt en een beetje aangepast en alleen de links overgelaten die echt nuttig zijn op de kiosk. Voor nu is de klant tevreden want er zijn nu geen linkjes meer waar iemand op kan klikken die daarna niet werken.

Als iemand die de kiosk gebruikt een heleboel links diep gaat kan het wel gebeuren dat die er nog zijn (want dat zit hij niet meer op onze statische pagina's).

Ik ga ook momenteel niet uitvogelen of ik de software met andere browsers aan de praat kan krijgen maar ik ben aan het experimenteren met een hoop linux distro's. De client software heeft een ubuntu versie. Maar daar moet eerst flink mee gespeeld worden voor we het in een live omgeving durven te gebruiken.

Thx voor alle hulp en zelfs hele scripjes die ter plekke in elkaar geknuselt werden. Jullie zijn geweldig!

[R4gnax]

Kain_niaK schreef op donderdag 24 juli 2014 @ 00:30:

Voorlopig is het zo opgelost. We hebben een aantal pagina's statisch gemaakt en gehost op onze eigen server. En dan alle _blank weggehaalt. Kortom, we hebben de frontpage van de jobbank van het internet gepakt en een beetje aangepast en alleen de links overgelaten die echt nuttig zijn op de kiosk. Voor nu is de klant tevreden want er zijn nu geen linkjes meer waar iemand op kan klikken die daarna niet werken.

Heb je hiervoor toestemming van de jobbank? Dit is namelijk een wijziging en herpublicatie van intellectueel eigendom waarvan de rechten bij de jobbank liggen en niet bij jou of jouw directe klant (tenzij dat diezelfde jobbank is, natuurlijk). Aangezien je de content en werking van de pagina aanpast kun je je niet op dezelfde regelingen in de wet beroepen als, pak hem beet, een caching proxy.

Als je hiervoor geen toestemming hebt, dan kan dat nog wel eens lelijke gevolgen hebben.

[Kain_niaK]

Jobbank IS onze klant

[R4gnax]

Kain_niaK schreef op vrijdag 25 juli 2014 @ 07:13:
Jobbank IS onze klant

In dat geval zal het vast wel in orde zijn.