[js] IE alternatief voor Object.watch?

[flowerp]

Weet iemand een alternatief voor de Object.watch/Object.unwatch functionaliteit van Mozilla browsers in Internet Explorer?

Ik heb dit nodig voor een pagina waar scriptjes op kunnen draaien die ik zelf niet onder controlle heb. Hiervoor wil ik in de gaten houden wanneer window.location verandert wordt. In de Mozilla browsers kan dat bijna niet makkelijker:

JavaScript:

function locationChanged(property, oldval, newval) { 
    alert ( 'new value: ' + newval ); 
    return newval;
}

if ( self.watch ) {
     self.watch( "location", locationChanged );
}

Helaas werkt dit niet onder IE. Er is iets wat in de buurt komt, onpropertychanged, maar die kan niet gebruikt worden op windows.location. Ik heb nog wel zitten te denken aan timers, maar dat lijkt me niet echt een hele elegante oplossing.

Iemand die iets beters weet?

[Verwijderd]

Als de location verandert, dan verlaat je toch de huidige pagina?
Als dat zo is, dan kun je het met een window.onunload doen. Het is bovendien zo, dat je het niet redt met timers wanneer de pagina wordt verlaten, omdat dan de uitvoering van het script wordt afgebroken.

[flowerp]

Verwijderd schreef op zaterdag 07 juli 2007 @ 10:48:
Als de location verandert, dan verlaat je toch de huidige pagina?
Als dat zo is, dan kun je het met een window.onunload doen.

Als het leven zo makkelijk was

Maar nee, dat werkt helaas niet, omdat je tijdens een window.onunload niet kan inlezen wat de nieuwe window.location is. Je krijgt gewoon de oude (huidige) waarde.

Het is bovendien zo, dat je het niet redt met timers wanneer de pagina wordt verlaten, omdat dan de uitvoering van het script wordt afgebroken.

Het idee was dan om iframes te gebruiken waarbij de parent window via timers telkens de location van de iframe checked.

[Verwijderd]

Maar nee, dat werkt helaas niet, omdat je tijdens een window.onunload niet kan inlezen wat de nieuwe window.location is. Je krijgt gewoon de oude (huidige) waarde.

Dat is express, vanwege veiligheidsoverwegingen. Volgens mij kun je ook niet een ander window scripten waarbij de locatie van een andere server komt.
En als de nieuwe locatie vanaf dezelfde server komt, kun je misschien daar wel iets mee? Bv door daar weer een window.onload te doen, dat kun je mooi als trigger gebruiken?

Misschien kun je iets specifieker zijn in wat je precies wilt bereiken

[Michali]

Je kunt op een (i)frame toch ook een onload event instellen? Kun je daar geen gebruik van maken? Maar als je toch geen controle hebt, dan kun je ook niet voorkomen dat het script zich uit zoiets breekt. Ik weet niet hoe belangrijk is dat het blijft werken.

[flowerp]

Verwijderd schreef op zaterdag 07 juli 2007 @ 11:38:
[...]
Dat is express, vanwege veiligheidsoverwegingen.

In dat geval niet, want in de onunload ben ik nog binnen 'mezelf' als script. Het zelfde effect treed op als ik een nieuwe waarde in window.location schrijf en hem dan meteen weer uitlees. Dan krijg ik ook de oude waarde i.p.v. de waarde die ik net schreef.

Michali schreef op zaterdag 07 juli 2007 @ 11:41:
Je kunt op een (i)frame toch ook een onload event instellen? Kun je daar geen gebruik van maken?

Inderdaad, daar zat ik net aan te denken. Dat is inderdaad iets wat zou kunnen werken, als er tenminste geen verdere beperkingen aan zitten.

Wat ik wil bereiken is een nogal complexe server-side en ajax opzet, maar het verhaal van de openingspost is zeg maar de abstractie ervan.

[flowerp]

flowerp schreef op zaterdag 07 juli 2007 @ 12:49:
Inderdaad, daar zat ik net aan te denken. Dat is inderdaad iets wat zou kunnen werken, als er tenminste geen verdere beperkingen aan zitten.

Helaas zaten er inderdaad beperkingen aan. Een onload handler gedefineerd op het iframe element zelf vuurt wel nadat er in dat iframe een nieuw document is geladen, maar vervolgens mag ik natuurlijk vanwege de security niet de window.location uitlezen:

HTML:

<script type="text/javascript">
   function ponload() {
      alert ( 'ponload called. location=' + window.frames['test'].document.location.href );
   }
</script>

<iframe onload="ponload()" id="test" name="test" src="test.html" ></iframe>

Binnen het bewuste iframe heb ik initieel echter wel bijna het hele document onder controlle (ik kan de html head en body elementen bepalen), dus zou ik daar van security issues geen last moeten hebben.

Wat ik dus zoek is een manier om de window.location(.href) die net geschreven is, ook weer uit te lezen. De 'pending' navigatie actie zeg maar:

Het gaat dus om het volgende stukje code:

JavaScript:

// trigger navigatie:
window.location = "http://www.tweakers.net";

// Hoe nu binnen dit zelfde scipt "http://www.tweakers.net" terug te lezen?

alert ( window.location ); // werkt niet; geeft oude waarde

Iemand nog enig idee?

[Michali]

Zie je een mogelijkheid om de betreffende scriptjes te herschrijven (automatisch)? Je zou assignments aan location(.href) kunnen vervangen door een eigen stukje code, maar dat zou ook vrij lastig kunnen zijn. Ik weet niet of dat de moeite waard is.

[flowerp]

Michali schreef op zondag 08 juli 2007 @ 17:27:
Je zou assignments aan location(.href) kunnen vervangen door een eigen stukje code, maar dat zou ook vrij lastig kunnen zijn.

Daar zat ik als alternatief ook aan te denken. Het is inderdaad vrij lastig. Om het echt goed te doen zou je een javascript parser moeten hebben. Vanaf een abstracte syntax tree kun je een boel doen, maar dan nog lijkt het me tricky business. Met reguliere expressies kun je eigenlijk alleen de directe cases afvangen. Stel het volgende voor:

JavaScript:

function doLoadNew(x) {
   x = newURL; // newURL = globale var included uit ander scriptje
}

var y = window;
var yy = y.location;
doLoadNew(yy);

Dit is zo op het eerste oog vrij absurd, maar als onderdeel van sommige scripts kom je dergelijke constructies wel tegen

Een workaround die me ook zou helpen is als ik binnen mijn script alleen kom te weten -dat- window.location veranderd is, de exacte nieuwe waarde hoef ik dan niet perse te weten. onunload is hierbij een aanwijzing, maar die vuurt ook als de gebruiker in het parent document een nieuwe pagina laad of de hele browser afsluit.

Het dichtste waarbij ik nu kom is in de onload handler proberen van de iframe de location uit te lezen met een exception handler er om heen. Als de exception er komt weet ik dat het document veranderd is, maar dat is eigenlijk te laat.

Wat ook een mogelijkheid zou zijn is dat ik op de een of andere manier IE kan bewegen om altijd veranderingen aan location.href in een nieuw window te openen. Een soort default target="_blank", maar dan voor location veranderingen. Maar ook dat is niet mogelijk denk ik.

Het is echt heel jammer dat Internet Explorer dat Object.watch niet kent, want die doet echt exact wat ik nodig heb.

[flowerp]

Iemand nog een idee?

[Michali]

Ik was net even aan het zoeken toen ik hier op stuitte. Vooral de 2de reactie is wel interessant om te lezen. Misschien heb je hier wat aan.

Heeft overigens niet echt met jouw probleem te maken, maar er wordt wel gezegd dat het niet mogelijk is om window.location wijzigingen te monitoren in IE, dus dan weet je hoe je er voor staat.

[ Voor 32% gewijzigd door Michali op 11-07-2007 11:15 ]

[flowerp]

Michali schreef op woensdag 11 juli 2007 @ 11:13:
Heeft overigens niet echt met jouw probleem te maken, maar er wordt wel gezegd dat het niet mogelijk is om window.location wijzigingen te monitoren in IE, dus dan weet je hoe je er voor staat.

Inderdaad, deze had ik al gelezen. Ik snap niet helemaal hoe je het uberhaupt met een timer kan doen. Na een navigatie actie worden alle actieve timers toch gekilled? Dit is namelijk ook 1 van de dingen die ik heb geprobeerd. In onunload een timer zetten die na b.v. 2 seconden de nieuwe location uitleest, maar die timer wordt nooit aangeroepen.

Het probleem in bovenstaande post was dat bij back-button acties location.href niet veranderd. In mijn situatie veranderd die location.href wel degelijk, alleen ik kan hem niet te weten komen.

Als simpelste voorbeeld; als ik in de iframe eerst een document laad wat via een alert de location.href laat zien, dan via een gewone hyperlink in de frame naar een nieuw document navigeer dat ook weer de location.href laat zien, dan is deze wel degelijk anders.

Als de hyperlink, of een directe location.href verandering, naar een extern document gaat, dan kan ik echter niet meer zien waar die heen gaat.

Ik snap dat er security issues zijn, en dat het onredelijk is om te verlangen dat ik de content van een iframe (zelfs de location) zou kunnen uitlezen vanaf het parent document. Het is goed dat alle browser vendors dit niet toestaan.

Wat ik echter wil, is dat ik in mijn eigen document, nog voor dat de navigatie daadwerkelijk off-site gaat, kan zien waar de user heen gaat. Dat kan dus redelijkerwijs alleen een link zijn die ik sowieso al heb, dus zouden er geen security issues aan moeten zitten.

b.v.

HTML:

<a href="#" onclick="window.location='http://www.tweakers.net';" > tweakers </a>
<a href="#" onclick="window.location='http://www.dzone.com';" > dzone </a>
<a href="#" onclick="window.location='http://www.theserverside.com';" > tss </a>

<!-- Welke link koos de gebruiker? -->

[T-MOB]

flowerp schreef op woensdag 11 juli 2007 @ 13:00:
[...]

HTML:

<a href="#" onclick="window.location='http://www.tweakers.net';" > tweakers </a>
<a href="#" onclick="window.location='http://www.dzone.com';" > dzone </a>
<a href="#" onclick="window.location='http://www.theserverside.com';" > tss </a>

<!-- Welke link koos de gebruiker? -->

Als het op je eigen pagina is dan heb je toch controle over de html. Jouw (ongetwijfeld versimpelde) voorbeeld kun je ook zo oplossen:

HTML:

<a href="http://www.tweakers.net" onclick="return catch_href(this)">tweakers</a>
<a href="http://www.dzone.com" onclick="return catch_href(this)">dzone</a>
<a href="http://www.theserverside.com" onclick="return catch_href(this)">tss</a>

<script type="text/javascript">
function catch_href(a) {
  return (confirm('Go to ' + a.href + '?'));
}
</script>

Een [s]behoorlijk[s] extreem ranzige manier om veranderingen aan window.location af te vangen is om de onclick van elementen in een aparte functiescope uit te voeren. Een enigszins werkend concept vangt onclick op a elementen af. Of ik het zou gebruiken is een tweede, ik voorzie een hoop mogelijke problemen...

HTML:

<html>
<head>
<script type="text/javascript">
function init() {
    var as = document.getElementsByTagName('a');
    var asc = as.length;
    for (var i=0; i<asc; i++) {
        var a = as[i];
        if (a.onclick) {
            //fetch the onclick attribute into a string
            var onclickStr = a.getAttribute('onclick');

            //create a wrapper to run the function in
            a.onclick = createWrappedHandler(onclickStr);
        }
    }
}

//create wrapper to catch modifications to "window".
function createWrappedHandler(str) {
    var func = function() {
        //IE has very bad support for getAttribute, it adds
        //"function anonymous() " around the onclick function
        //Here we hack around that behaviour:

        var code = str + '; anonymous();';

        var window = new Object();
        window.location = false;
        eval(code);
        if (window.location) {
            alert(window.location);
        }
    };
    return func;
}

window.onload = init;
</script>
</head>

<body>
<ul>
  <li><a href="#" onclick="window.location='http://www.tweakers.net';" >tweakers</a>
  <li><a href="#" onclick="window.location='http://www.dzone.com';" >dzone</a>
  <li><a href="#" onclick="window.location='http://www.theserverside.com';" >tss</a>
</ul>

<a href="http://nu.nl">No onclick</a>

</body>
</html>

[ Voor 46% gewijzigd door T-MOB op 11-07-2007 16:50 ]

[flowerp]

T-MOB schreef op woensdag 11 juli 2007 @ 15:55:
[...]
Als het op je eigen pagina is dan heb je toch controle over de html. Jouw (ongetwijfeld versimpelde) voorbeeld kun je ook zo oplossen.

Nou, ik heb controle over de head en bottom van de pagina, maar niet over het middenstuk. Schematisch is het dus:

HTML:

<!-- start onder mijn controle -->
<html>
  <head></head>
  <body>
     <!-- diverse HTML en/of scripts -->
<!-- eind mijn controle -->

     <!-- diverse HTML en/of scripts -->

<!-- start onder mijn controle -->
     <!-- diverse HTML en/of scripts -->
     </body>
</html>
<!-- eind mijn controle -->

Het middenstuk kan potentieel de window.location veranderen. Dat zou dus ook bijvoorbeeld direct een javascript kunnen zijn, maar ook bijvoorbeeld een onchange op een select element.

Voor een gelimiteerd aantal cases zou jouw 2de voorstel misschien wel een oplossing zijn. Ik kan dan de elementen in de page aflopen en programmatisch onchange en onclick handlers wrappen.

[SchizoDuckie]

Misschien een gekke vraag hoor, maar volgens mij ben je een eind heen aan't hacken terwijl je het probleem op een heel andere manier misschien nog veel beter aan kan pakken. Wat probeer je precies te doen? want de situatie die je hierboven schetst is wel écht heel erg wazig...

[flowerp]

SchizoDuckie schreef op woensdag 11 juli 2007 @ 23:25:
Misschien een gekke vraag hoor, maar volgens mij ben je een eind heen aan't hacken terwijl je het probleem op een heel andere manier misschien nog veel beter aan kan pakken. Wat probeer je precies te doen? want de situatie die je hierboven schetst is wel écht heel erg wazig...

De wazigheid valt denk ik absoluut mee. Het is een pagina met iframes, en binnen deze iframes worden HTML fragmenten gezet. De bedoeling was eigenlijk dat dit door AJAX zou gebeuren, maar die opzet heb ik nu even laten zitten.

De fragmenten heb ik niet onder controle (die kan een (trusted) user invoeren), maar de rendering van die fragmenten wel. Omdat het fragmenten betreffen, kan ik er zelf de html en body tags om heen zetten.

De fragmenten moeten in de iframes blijven staan, bij een navigatie actie mag de nieuwe pagina deze fragmenten niet overschrijven. Het ziet er ook heel lelijk uit na een navigatie. Een fragment kan 1 regel zijn, en een iframe resized niet automatisch mee in de hoogte.

In Firefox heb ik dit perfect allemaal op kunnen vangen. De pagina werkt uitstekend, en iedereen is er uiterst tevreden mee hoe het nu werkt. Totdat iemand met Internet Explorer aankwam. Ik dacht het even snel met een IE specifiek code path op te lossen, maar ik zit al bijna 2 weken het halve internet af te struinen naar oplossingen en kom amper verder.

Een (lelijke) workaround is de user de iframe laten resizen, en een knop om de originele content weer terug te zetten. Alsof de duivel er mee speelt, werkt die laatste knop ook al niet. Wat ik doe is simpelweg:

HTML:

<a href="#" onclick="window.frames('test').document.location.href='about:blank'; return false;" > set test  </a>

Deze workaround voor het oorspronkelijke probleem levert een keihard "Access is denied." error op in IE6.

Volgens Microsofts eigen documentatie zou het moeten kunnen:

Since it is important to be able to navigate windows or frames to any URL beyond the domain restriction, these types of accesses are always permitted. Only access that attempts to read out or modify content is restricted. For instance, the href property might be assigned to cause navigation to occur, but this property cannot be read if the URL is of a different domain.

bron: http://msdn2.microsoft.com/en-us/library/ms533028.aspx

Update:
window.frames('test').location ipv window.frames('test').document.location blijkt wel te werken als de iframe een extern document bevat. Als het een document bevat van binnen hetzelfde domein werken allebei de varianten.

[ Voor 4% gewijzigd door flowerp op 12-07-2007 00:19 ]

[SchizoDuckie]

Ik denk dat je toch echt met een simpele ajax snippet een stuk meer controle hebt over de layout van je pagina. Het is zó makkelijk om m.b.v. 1 ajax requestje een stukje pagina op te vragen en dit in een al voorgedefinieerde content div te plempen dat je waarschijnlijk jezelf voor je hoofd gaat slaan... Even een voorbeeldje m.b.v. mootools

JavaScript:

 new Ajax('http://www.zelfdedomein.nl/contentvangebruiker/contentvanpietje.html', { update: 'divNaampje'}).request(); // sleept alle inhoud uit contentvanpietje.html en plempt dit in de container met ID divNaampje

Voor het geval je toch met je iframes wil blijven doorprutsen:

Wat je dus eigenlijk wil is dat je iframe z'n eigen hoogte/breedte door passed aan de 'parent' pagina?

Als je ook nog controle hebt over

Watch & Learn:

In de 'trusted' pagina (die dus door een ander gebouwd is) zorg je dat er in de content staat:

HTML:

<script>

  function parentResize()
  {
      parent.updateIframeSize(document.body.scrollWidth, document.body.scrollHeight);
  }

</script>

In je 'container' page (waar al je iframes instaan dus)

JavaScript:

function updateIframeSize(width, height)
{
  $('iframe').height = height + 20;;
  $('iframe').width = width+20;
}
// waarbij $('iframe') een wrapper is voor document.getElementById('iframe')

Suc6!

[flowerp]

SchizoDuckie schreef op donderdag 12 juli 2007 @ 09:25:
en plempt dit in de container met ID divNaampje

Divs zijn in mijn geval niet bruikbaar. De HTML fragmenten moeten zoveel mogelijk onafhankelijk getoond worden, en kunnen ook forms bevatten. Om de hele pagina staat ook al een form (het is een JSF pagina), dus dat gaat zeker niet werken. Daarnaast wordt de styling van content in div containers beïnvloed door de styling op de rest van de pagina, bij iframes is dat niet het geval.

Een iframe is een veel meer geïsoleerde context, eigenlijk een echte local scope binnen een HTML document. Het is wel jammer dat er niet gewoon een officiele no-nonsense local scope bestaat binnen het DOM model (zoals je bijvoorbeeld wel in diversen programmeertalen hebt).

Ik schrijf nu lokaal de content in een iframe (gebruik dus niet het src attribuut) en resize deze dan naar de exacte grote van de content. Dat resizen is ook iets meer involved als jij nu laat zien . Voor Opera, Safari 2, Internet Explorer en Firefox gebruik je telkens net even andere code.

[crisp]

flowerp schreef op donderdag 12 juli 2007 @ 00:06:
[...]

Update:
window.frames('test').location ipv window.frames('test').document.location blijkt wel te werken als de iframe een extern document bevat. Als het een document bevat van binnen hetzelfde domein werken allebei de varianten.

http://therealcrisp.xs4al...document-window-location/

flowerp schreef op donderdag 12 juli 2007 @ 22:15:
[...]
Een iframe is een veel meer geïsoleerde context, eigenlijk een echte local scope binnen een HTML document. Het is wel jammer dat er niet gewoon een officiele no-nonsense local scope bestaat binnen het DOM model (zoals je bijvoorbeeld wel in diversen programmeertalen hebt).

fwiw: HTML5 beschrijft iig alvast <style scoped>. Het is een onderkent probleem maar een oplossing vinden die ook nog eens gracefull degrade in oudere (lees: huidige) browsers is lastig, en zolang er browsers zijn die zelfs nog niet eens 60% van CSS2.1 ondersteunen is het allemaal nog verre toekomstmuziek...

[Niemand_Anders]

object.(un)watch is onderdeel van javascrip 1.5. Momenteel ondersteunen alleen firefox en opera object.watch.

Wil je toch weten op welke link jouw bezoeker klikte, gebruik dan een redirect script (redirect.jsp?code=tweakers). Dat werkt in alle browsers. En je kunt later ook nog statistieken tonen wat de populairste link in week xx.

Google gebruikt een soort gelijke techniek bij hun resultaten. In de statusbar zie je de website url staan, maar zodra je op de link klikt ga je eerst langs de google server (kijk maar eens in de source). Op deze manier weet google of dat het zoekresultaat goed was of naar een concurrent bent gegaan.

[crisp]

Niemand_Anders schreef op zaterdag 14 juli 2007 @ 14:42:
object.(un)watch is onderdeel van javascrip 1.5. Momenteel ondersteunen alleen firefox en opera object.watch.

quote: http://developer.mozilla....ence:Objects:Object:watch

Implemented in: JavaScript 1.2, NES 3.0

Het is dus al wat ouder. Het is mij echter niet bekend welke browsers het precies wel of niet ondersteunen buiten Firefox en Opera (wel) en IE (niet)

[ Voor 16% gewijzigd door crisp op 14-07-2007 14:51 ]

[flowerp]

crisp schreef op zaterdag 14 juli 2007 @ 14:50:
Het is dus al wat ouder. Het is mij echter niet bekend welke browsers het precies wel of niet ondersteunen buiten Firefox en Opera (wel) en IE (niet)

Het is zeker al wat ouder. Ik kan me zelfs herinneren dat er al in Netscape 3 (of 4) iets was wat hier sterk op leek, iets met getter/setter. Des te onbegrijpelijker dat MS het in al die velen jaren nog niet geïmplementeerd heeft. Zelfs in IE 7 kan het niet.

@Niemand_Anders
Ik waardeer je suggestie hoor voor de redirect links, maar als je een beetje de thread gelezen had, dan had je kunnen zien dat zoiets totaal niet de bedoeling is. Ik heb te maken met HTML fragmenten die niet van mezelf komen. Alleen wat onder of boven het fragment staat kan ik bepalen.