Ernstes Problem mit window.name in MSIE 5.5
Hatto von Hatzfeld
Eine Rückmeldung auf meinen Wertübergabe-Artikel in SELFAKTUELL stellt
Folgendes fest: Mindestens ein Exemplar des MSIE 5.5 (Service Pack 1,
Rel.-Nr. 5.50.4522.180) scheint eine Änderung von window.name nicht
mehr zu erlauben, wenn dieses Fenster mit
<a href="..." target="neuername">...</a>
geöffnet wurde. Genauer gesagt: man kann den Namen zwar per Javascript
ändern, aber beim unload des darin angezeigten Dokumentes wird er wieder
auf den beim Öffnen zugewiesenen Namen zurückgesetzt. Ja, Ihr habt
richtig gelesen! Allerdings konnte ich mangels eines MSIE 5.5 das nicht
testen (mein MSIE 5 hat das Problem jedenfalls nicht). So habe ich eine
Testseite erstellt, auf die ich hiermit Nutzer des MSIE 5.5 herzlich
einlade:
http://www.salesianer.de/util/wnametest.html
Dort wäre nichts zu tun als jedem der beiden Links 2 Stufen weit zu
folgen. Und schreibt hier dann bitte, ob irgendwelche Fehler
(insbesondere auch "erwartete" Fehler) gemeldet werden. Zusätzlich zum
Öffnen per target=".." habe ich dort alternativ auch ein Öffnen per
window.open vorgesehen. Sollte das Problem sich bestätigen, so wird man
unseren window.name-Trick vergessen müssen. Denn das Verhalten zeigt
sich - laut der genannten Rückmeldung - gerade (auch?) dann, wenn das
Fenster vorher auf einer anderen Website (d.h. unter einer Domain)
geöffnet wurde, kann also durch eine Website selbst nicht kontrolliert
werden. Bei target="" (und vermutlich auch bei target="_blank") tritt
das Phänomen nicht auf.
Einen Sinn kann ich in der Neuerung nicht sehen, sondern nur einen neuen
Bug.
Gespannt auf Eure Antworten,
Hatto
--
Un égoiste est quelqu'un qui ne pense pas à moi.
(Eugène Labiche)
Michael Praast
"Hatto von Hatzfeld" <ha...@salesianer.de> schrieb:
> http://www.salesianer.de/util/wnametest.html
window.open:
(Ihr Browser ist ein Microsoft Internet Explorer 4.0 (compatible; MSIE
5.5; Windows 95))
Erwarteter Fehler: window.name="h976370285310"
Eigentlich hätte der Wert so lauten müssen: s976370287400
target:
(Ihr Browser ist ein Microsoft Internet Explorer 4.0 (compatible; MSIE
5.5; Windows 95))
Erwarteter Fehler: window.name="h976370237190"
Eigentlich hätte der Wert so lauten müssen: s976370259710
Hatte ich das Problem nicht schonmal berichtet, seinerzeit aber mit
IE5.01?
Best regards
Michael
«
--
Leben ist das, was Du daraus machst. Die Chancen liegen bei Dir.
Hompäitsch: http://www.praast.de/ FAQ dieser Gruppe:
http://www.mintert.com/javascript/de.comp.lang.javascript.html
FFQ (nicht gern gesehene Fragen): http://www.praast.de/ffq/
Christine Kuehnel
de.comp.lang.javascript:
>Folgendes fest: Mindestens ein Exemplar des MSIE 5.5 (Service Pack 1,
>Rel.-Nr. 5.50.4522.180) scheint eine Änderung von window.name nicht
>mehr zu erlauben, wenn dieses Fenster mit
> <a href="..." target="neuername">...</a>
Das ist noch nicht die vollstaendige Erklaerung.
Ich steige noch nicht so recht durch, deswegen zuerst mal meine
Beobachtungen:
- http://www.salesianer.de/util/wnametest.html
- Für Test mit target bitte hier klicken!
- wnametest1.html erscheint in neuem Fenster, und das behauptet, es
hiesse: (window.name=)h976379342520,
obwohl ein Blick in Quelltext sagt, dass window.name neu gesetzt
sein muesste - window.name='s'+dan;
- abweichend von der vorgegebenen Testanordnung benutze ich jetzt
"Aktualisieren", Ergebnis:
Unerwarteter Fehler: window.name="s976381033510"
Eigentlich hätte der Wert so lauten müssen: h976379342520
D.h., das "s" muss irgendwann gewirkt haben.
Wann?
Folge ich Deiner Vorgabe, klicke die Links ohne Umweg, dann passiert
in wnametest2.html das, was auch Michael beobachtet hat - s wird
erwartet, h ist es.
Danach "Zurueck" per Button bringt schoenste Harmonie - alles h.
Ich habe so das recht diffuse Gefuehl, es haengt mit der
Abarbeitungsfolge der Anweisungen zusammen.
Wer von Euch war da gleich so richtig sattelfest in dem Thema?
Thomas? Georg? Wer anders?
Beim Navi laeuft das etwas anders, da kann man so richtig schoen
beobachten, dass die Reihenfolge der Abarbeitung genau die ist, in der
die Anweisungen geschrieben wurden.
Der stellt wnametest1.html zunaechst Uebereinstimmung (h) fest, setzt
window.name dann auf s..., denn nachdem geladen steht da drin:
window.name=s976381762210
Ganz logisch hat er dann nateurlich was dagegen, dass man einfach den
Back-Button benutzt, denn dann wird h erwartet, und s ist drin - alles
prima nachvollziehbar.
>geöffnet wurde. Genauer gesagt: man kann den Namen zwar per Javascript
>ändern, aber beim unload des darin angezeigten Dokumentes wird er wieder
~~~~~~~~
|--- das scheint es mir nicht zu sein
>window.open vorgesehen. Sollte das Problem sich bestätigen, so wird man
>unseren window.name-Trick vergessen müssen.
Nein, nicht so schnell die Flinte ins Korn werfen.
Was soll sie denn da? ;-)
Bleibt man in einem namenlosen Fenster, geht es sicher nach wie vor.
Ich wuesste nicht, warum nicht.
Das Problem ist Setzen von name fuer dasselbe Fenster auf
unterschiedlichen Wegen (target und JS-Anweisung).
Wenn man rausfindet, was da wann genau passiert, das dann auch noch
begreifen kann, weil Logik erkennbar, dann geht es unter Beachtung
dessen sicher auch weiterhin.
>sich - laut der genannten Rückmeldung - gerade (auch?) dann, wenn das
>Fenster vorher auf einer anderen Website (d.h. unter einer Domain)
>geöffnet wurde, kann also durch eine Website selbst nicht kontrolliert
>werden.
Hm, einmaliges Putzen vorab muesste sich doch irgendwie machen
lassen(?). Fehlt nur noch die Stelle, die gefegt werden muss.
>Einen Sinn kann ich in der Neuerung nicht sehen, sondern nur einen neuen
>Bug.
Oder (s.o.) nur eine Folge von Aenderungen an anderer Stelle
(Abarbeitung der Anweisungen).
Wer weiss weiter?
Christine
--
meine JavaScript-Notizen jetzt auf http://www.netz-notizen.de/javascript/
Web-Site zu de.comp.lang.javascript (inkl. FAQ):
http://www.mintert.com/javascript/de.comp.lang.javascript.html
FAQ direkt fuer ganz Eilige z.Zt.:
http://screenexa.net/de.comp.lang.javascript/faq/
Hatto von Hatzfeld
> Hi,
> "Hatto von Hatzfeld" <ha...@salesianer.de> schrieb:
>> http://www.salesianer.de/util/wnametest.html
>
> window.open:
> (Ihr Browser ist ein Microsoft Internet Explorer 4.0 (compatible; MSIE
> 5.5; Windows 95))
> Erwarteter Fehler: window.name="h976370285310"
> Eigentlich hätte der Wert so lauten müssen: s976370287400
>
> target:
> (Ihr Browser ist ein Microsoft Internet Explorer 4.0 (compatible; MSIE
> 5.5; Windows 95))
> Erwarteter Fehler: window.name="h976370237190"
> Eigentlich hätte der Wert so lauten müssen: s976370259710
>
> Hatte ich das Problem nicht schonmal berichtet, seinerzeit aber mit
> IE5.01?
Das musst Du wissen :-) Ich jedenfalls habe es nicht mitbekommen
(passierte vielleicht in einer meiner Auszeiten), und in deja habe ich
auch nichts gefunden. Kannst Du (oder sonst jemand) mir kurz mitteilen,
was die genauen Bedingungen für diesen Fehler sind? Ist es so, dass jede
Zuweisung eines nichtleeren Namens an ein Fenster, die direkt mit dem
Öffnen verbunden ist (also per target oder window.open), diesen Effekt
hervorruft?
Wie auch immer das genau ist - die Konsequenzen finde ich schon sehr
ärgerlich. Wenn Du z.B. in Fireball bei den Treffern auf die Zeile mit
dem Fenstersymbol klickst, dann ist das ein Link mit target="Firetop",
und wenn die so mit Hilfe der Suchmaschine gefundene Seite window.name
zur Wertübergabe nutzt (was sogar ein kommerziell erstelltes Shop-Script
tut), dann funktioniert es nicht. :-((
Ciao,
Hatto
--
Suche Posting nach Message-ID: http://www.deja.com/forms/mid.shtml
Link auf Posting: http://www.deja.com/msgid.xp?MID=<......@......>
oder besser: http://www.deja.com/msgid.xp?MID=%3C......%40.....%3E
Michael Praast
>>Hatte ich das Problem nicht schonmal berichtet, seinerzeit aber mit
>>IE5.01?
>
>Das musst Du wissen :-) Ich jedenfalls habe es nicht mitbekommen
>(passierte vielleicht in einer meiner Auszeiten), und in deja habe ich
>auch nichts gefunden.
http://www.deja.com/msid.xp?MID=<8rs32k$im3vu$2...@ID-50907.news.cis.dfn.de>
Ich hatte den Fehler unter IE5.5 (nicht 5.01) gesehen und hielt es für
einen Bug in meinem Browser (unter NT konnte ich den Fehler nicht
produzieren). Du hattest seinerzeit einen anderen Test (
http://www.salesianer.de/util/winname.html ) aufgesetzt. Grad nochmal
getestet, alle 7 Tests (sowohl W als auch S) ok.
>Kannst Du (oder sonst jemand) mir kurz mitteilen,
>was die genauen Bedingungen für diesen Fehler sind?
Leider nicht. Ich hatte es seinerzeit wie gesagt als Bug _meines_
Browsers abgetan und nicht weiter verfolgt.
>Wie auch immer das genau ist - die Konsequenzen finde ich schon sehr
>ärgerlich.
Vielleicht wirklich nur eine Frage der Anordnung, wie Christine vermutet?
Best regards
Michael
Michael Praast
Ich schrieb:
>Vielleicht wirklich nur eine Frage der Anordnung, wie Christine
vermutet?
Scheinbar ja, oder?
target/popup:
Fenster heißt jetzt: 'h976393031660'
Beim Aufruf dieser Seite hieß dieses Fenster: 's976393033310'
Bei normalem Aufruf dieser Seite sollten diese Werte identisch sein!
Führe aus: window.name='t976393040610'
Umbenennung erfolgreich.
Fenster heißt jetzt: 't976393040610'
Best regards
Michael
Hatto von Hatzfeld
> Hatto von Hatzfeld schrieb am Sat, 9 Dec 2000 14:18:46 +0100 in
> de.comp.lang.javascript:
>
>>Folgendes fest: Mindestens ein Exemplar des MSIE 5.5 (Service Pack 1,
>>Rel.-Nr. 5.50.4522.180) scheint eine Änderung von window.name nicht
>>mehr zu erlauben, wenn dieses Fenster mit
>> <a href="..." target="neuername">...</a>
>
> Das ist noch nicht die vollstaendige Erklaerung.
Hm, das sehe ich jetzt auch.
> Ich steige noch nicht so recht durch, deswegen zuerst mal meine
> Beobachtungen:
> - http://www.salesianer.de/util/wnametest.html
> - Für Test mit target bitte hier klicken!
> - wnametest1.html erscheint in neuem Fenster, und das behauptet, es
> hiesse: (window.name=)h976379342520,
Verstehe ich Dich richtig: z.B. mit dem DOM-Browser nach dem onload
angesehen, oder?
> obwohl ein Blick in Quelltext sagt, dass window.name neu gesetzt
> sein muesste - window.name='s'+dan;
> - abweichend von der vorgegebenen Testanordnung benutze ich jetzt
> "Aktualisieren", Ergebnis:
> Unerwarteter Fehler: window.name="s976381033510"
> Eigentlich hätte der Wert so lauten müssen: h976379342520
> D.h., das "s" muss irgendwann gewirkt haben.
> Wann?
Gute Frage...
OK, ich habe da also nicht an alle Möglichkeiten gedacht. Um es etwas
besser testen zu können, habe ich
http://www.salesianer.de/util/wnametest.html
jetzt etwas ausgeweitet; die Seite prüft sofort nach, ob die Umbenennung
erfolgreich war. Wenn Du nun also wieder testen willst... :-)
>>geöffnet wurde. Genauer gesagt: man kann den Namen zwar per Javascript
>>ändern, aber beim unload des darin angezeigten Dokumentes wird er wieder
> ~~~~~~~~
> |--- das scheint es mir nicht zu sein
>
>>window.open vorgesehen. Sollte das Problem sich bestätigen, so wird man
>>unseren window.name-Trick vergessen müssen.
>
> Nein, nicht so schnell die Flinte ins Korn werfen.
> Was soll sie denn da? ;-)
Stimmt - erst wenn man mal kapiert hat, was da passiert, sollte man
definitive Schlussfolgerungen ziehen.
> Bleibt man in einem namenlosen Fenster, geht es sicher nach wie vor.
> Ich wuesste nicht, warum nicht.
Das Problem ist halt, dass man nur durch eigenes Öffnen eines namenlosen
Fenster diesen Zustand garantieren kann; denn - wie ich anderswo schon
schrieb - gehen z.B. von der Fireball-Trefferliste Links in benannte
Targets.
> Das Problem ist Setzen von name fuer dasselbe Fenster auf
> unterschiedlichen Wegen (target und JS-Anweisung).
> Wenn man rausfindet, was da wann genau passiert, das dann auch noch
> begreifen kann, weil Logik erkennbar,
OK - das sollte man abwarten.
> dann geht es unter Beachtung dessen sicher auch weiterhin.
Das hoffe ich auch, habe aber so meine Zweifel...
> Wer weiss weiter?
Tja...
Ciao,
Hatto
--
Aktion für mehr Demokratie im Usenet:
http://www.christkath.ch/usenet/Mitmach-FAQ.txt
Michael Praast
>> - abweichend von der vorgegebenen Testanordnung benutze ich jetzt
>> "Aktualisieren", Ergebnis:
>> Unerwarteter Fehler: window.name="s976381033510"
>> Eigentlich hätte der Wert so lauten müssen: h976379342520
>> D.h., das "s" muss irgendwann gewirkt haben.
>> Wann?
Nach onload des _neuen_ Fensters, wenn bisher window.name existierte.
Ich hatte das Ganze mal auf Namen umgestellt:
1. Fenster (test.htm/ohne Name):
test.htm (kein Name, weder Head, Body noch onload)
test.htm ruft Fenster namens 'heinz' auf.
2. Fenster (test1.htm/heinz):
Im Head 'heinz', im Aufbau (Body) 'heinz' vor Umbenennung.
Dann Umbennennung auf 'sofie' im Body. onload zeigt 'sofie' an.
'sofie' ruft nun test2.htm auf.
3. Fenster (test2.htm/sollte sofie heißen):
'sofie' nennt sich im Head 'heinz'(!), im Body dann vor Umbenennung
'heinz', nach Umbenennung im Body und onload 'timo'.
Hilft euch das irgendwie weiter? Achja, 'sofie' wird irgendwie nie
übergeben, egal wie oft ich die Umbenennung versuche.
Best regards
Michael
Michael Praast
"Michael Praast" <mic...@praast.de> meißelte:
>Nach onload des _neuen_ Fensters, wenn bisher window.name existierte.
...aber nicht permanent. Sorry, vergass ich zu erwähnen.
>3. Fenster (test2.htm/sollte sofie heißen):
> 'sofie' nennt sich im Head 'heinz'(!), im Body dann vor Umbenennung
> 'heinz', nach Umbenennung im Body und onload 'timo'.
4. Fenster (test3.htm/sollte timo heißen):
'timo' nennt sich im Head 'heinz'(!), im Body dann vor Umbenennung
'heinz', nach Umbenennung im Body und onload 'klaus'.
5. Fenster (test4.htm/sollte klaus heißen):
'klaus' nennt sich im Head 'heinz'(!), im Body dann vor Umbenennung
'heinz', nach Umbenennung im Body und onload 'karin'.
...und so weiter...
Best regards
Michael
Hatto von Hatzfeld
Nun, wenn Du das auf der "Folgeseite 2" gesehen hast, dann entspricht
das genau meiner Befürchtung. Es heißt nämlich, dass auf der "Folgeseite
1" das Fenster erfolgreich (getestet!) zu 's976393033310' umbenannt
wurde, aber nach Ausführen des Links doch wieder den Namen hatte, den es
bei seiner Erschaffung bekommen hatte (das kann man auch am timestamp
sehen, der im Namen an den einen Buchstaben angehängt ist). Man kann
also in den window.name eines per target="..." geöffneten Fensters
reinschreiben, was man will; beim Laden eines anderen Dokumentes steht
da doch wieder der ursprüngliche Name. :-(
So, nun testet mal schön; ich diskutiere ab Mittwoch wieder mit :-)
Ciao,
Hatto
--
Zwei Dinge scheinen unendlich zu sein: das Universum
und die menschliche Dummheit. Beim Universum bin ich
mir nicht so sicher... (Albert Einstein)
Hatto von Hatzfeld
> Hi Hatto,
> "Hatto von Hatzfeld" <ha...@salesianer.de> schrieb:
>> Michael Praast <mic...@praast.de> schrieb:
>>>Hatte ich das Problem nicht schonmal berichtet, seinerzeit aber mit
>>>IE5.01?
>>
>>Das musst Du wissen :-) Ich jedenfalls habe es nicht mitbekommen
>>(passierte vielleicht in einer meiner Auszeiten), und in deja habe ich
>>auch nichts gefunden.
>
> http://www.deja.com/msid.xp?MID=<8rs32k$im3vu$2...@ID-50907.news.cis.dfn.de>
Ach so; das hatte ich schon erfolgreich verdrängt :-)
> Ich hatte den Fehler unter IE5.5 (nicht 5.01) gesehen und hielt es für
> einen Bug in meinem Browser (unter NT konnte ich den Fehler nicht
> produzieren). Du hattest seinerzeit einen anderen Test (
> http://www.salesianer.de/util/winname.html ) aufgesetzt. Grad nochmal
> getestet, alle 7 Tests (sowohl W als auch S) ok.
Ja, das dumme ist ja, dass für das Script auf der Seite selbst sich gar
nichts ändert, da window.name sich verhält wie eine x-beliebige Variable
im scope des Dokumentes und der Inhalt weg ist, wenn das Dokument weg
ist. Mein damaliger Test wechselte weder das Dokument noch war
sichergestellt, dass das Fenster mit target oder window.open geöffnet
worden war. Er sah nur noch, welche Arten von Zeichen in window.name
akzeptiert wurden, und fand beim MSIE keine diesbezüglichen Grenzen (wie
auch bei jeder gewöhnlichen Variablen, der ein String zugewiesen wird).
Hm, anscheinend *ist* window.name so etwas wie eine Variable, deren
Inhalt auf den wirklichen Fensternamen dann nicht mehr übertragen wird,
wenn dieser bei Erschaffung des Fensters einen nichtleeren Wert bekam.
Man müsste mal testen, wie das bei <frame name="..."> und nachträglicher
Änderung von frames[1].name aussieht, und ob target="..." auf ein per
window.name="..." benanntes, aber im o.g. Sinn umbenennungsrenitentes
Fenster funktioniert...
Aber das mache bitte mal jemand, der einen MSIE 5.5 hat.
Ciao,
Hatto
--
Treffen sich zwei Geraden. Sagt die eine:
"Beim nächsten Mal gibst du einen aus!"
Michael Praast
>also in den window.name eines per target="..." geöffneten Fensters
>reinschreiben, was man will; beim Laden eines anderen Dokumentes steht
>da doch wieder der ursprüngliche Name. :-(
Der dem target zugewiesene Wert, um genau zu sein.
Wenn du test2.html so aufrufst:
document.write(' <br><a href="wnametest2.html?"+window.name+"
target="+window.name">Für weiteren Test bitte hier klicken!<\/a>');
dann übernimmt er den neuen zugewiesenen Wert.
>So, nun testet mal schön; ich diskutiere ab Mittwoch wieder mit :-)
Jaja, erst anschubsen und dann abtauchen, tztztz. ;-)
Michael Praast
>Inhalt auf den wirklichen Fensternamen dann nicht mehr übertragen wird,
>wenn dieser bei Erschaffung des Fensters einen nichtleeren Wert bekam.
Bei neuen Fenstern hast du recht. Nachträgliche Änderungen verträgt er
dort nicht.
>Man müsste mal testen, wie das bei <frame name="..."> und nachträglicher
>Änderung von frames[1].name aussieht, und ob target="..." auf ein per
>window.name="..." benanntes, aber im o.g. Sinn umbenennungsrenitentes
>Fenster funktioniert...
Einen Teil kannst du hier testen: http://www.praast.de/hatto/
Best regards
Michael
Thomas Fischer
> Folgendes fest: Mindestens ein Exemplar des MSIE 5.5 (Service Pack 1,
> Rel.-Nr. 5.50.4522.180) scheint eine Änderung von window.name nicht
> mehr zu erlauben, wenn dieses Fenster mit
> <a href="..." target="neuername">...</a>
> geöffnet wurde.
*kreidebleich*
Bisher alle von mir getesteten IE5.5 SP1 haben diesen Bug:
win98, 5.50.4522.1800CO
win98, 5.50.4522.1800
win98, 5.50.4522.1800IC
win2000, 5.50.4522.1800
Worin der Unterschied zwischen "1800", "1800IC" und "1800CO" liegt,
weiß ich nicht. Allle IE5.5 ohne SP1 hatten den Bug nicht.
Eine Zuweisung a la:
name="newName";
alert(name);
brachte zwar "newName", ein "javascript:alert(name)" brachte aber wieder
den alten Namen. Nach einem unload oder Zugriff via "javascript:..."
wird window.name also wieder auf den Original-Wert gesetzt.
Frames und iFrames sind IMHO nicht betroffen.
Ich werde mal bei MS die Alarmglöckchen schwingen ...
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Georg Maaß
>
> Eine Zuweisung a la:
> name="newName";
> alert(name);
>
> brachte zwar "newName", ein "javascript:alert(name)" brachte aber wieder
> den alten Namen. Nach einem unload oder Zugriff via "javascript:..."
> wird window.name also wieder auf den Original-Wert gesetzt.
Heißt dies, daß Euer wüster Hack, den Fenster-Targenamen zur
persistenten Parameterübergabe zu mißbrauchen, mit diesen Browsern nicht
funktioniert?
Gruß, Georg
--
BUGOPOLY:
onbug=function(){return this.bug.to.author.and.receive['$4,000.00'];};
Georg Maaß - bioshop.de
JavaScript Engineering D-20535 Hamburg, Sievekingsallee 35
Thomas Fischer
>
> Heißt dies, daß Euer wüster Hack, den Fenster-Targenamen zur
Das ist KEIN "wuester Hack", sondern W3C-DOM-kompatible!
(siehe name-Attribut).
> [...] mit diesen Browsern nicht funktioniert?
Zumindest mit dem derzeit bereitgestellten SP1. Ich hoffe auf eine
schnelle Antwort von MS, ob es sich um ein Bug oder "Feature" handelt.
Zweiteres käme für mich (und viele andere?) einer Katastrophe gleich ...
PS:
Es gibt Gründe, warum in manchen Situationen Sessiondaten nicht Server-
seitig gehandelt werden können.
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Georg Maaß
>
> Georg Maaß <ge...@bioshop.de> schrieb:
> >
> > Heißt dies, daß Euer wüster Hack, den Fenster-Targenamen zur
> > persistenten Parameterübergabe zu mißbrauchen, [...]
>
> Das ist KEIN "wuester Hack", sondern W3C-DOM-kompatible!
Die Küchenrolle ist auch Toiletten kompatibel, und trotzdem nimmst Du
Klopapier...
Oder sollte ich mich so sehr in Dir getäuscht haben?
Best Wisch, Georg
Michael Praast
"Thomas Fischer" <Thomas....@tool42.com> schrieb:
> Bisher alle von mir getesteten IE5.5 SP1 haben diesen Bug:
> win98, 5.50.4522.1800CO
> win98, 5.50.4522.1800
> win98, 5.50.4522.1800IC
> win2000, 5.50.4522.1800
Nur, um noch ein Glöcklein hinzuzufügen:
W95, 5.50.4134.0600IC
> Ich werde mal bei MS die Alarmglöckchen schwingen ...
<sing>Süsser die Glöcklein nicht klingen, als...</sing> SCNR
Best regards
Michael
Thomas Fischer
huhu,
> Nur, um noch ein Glöcklein hinzuzufügen:
> W95, 5.50.4134.0600IC
Komisch, ich hatte ein "5.50.4134.0600" als auch "5.50.4134.0600CO"
getestet - beide bugfrei! Bist Du Dir gaaanz sicher? (mein Script)
Ist das ein IE 5.5 mit ServicePack 1? Hast Du eine Ahnung was die
zwei optionalen Buchstaben am Ende bedeuten?
... Fragen über Fragen
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Michael Praast
"Thomas Fischer" <thomas....@tool42.com> schrieb:
>Komisch, ich hatte ein "5.50.4134.0600" als auch "5.50.4134.0600CO"
>getestet - beide bugfrei! Bist Du Dir gaaanz sicher? (mein Script)
Nein, dein Script hatte ich nicht getestet, aber macht das, was bei Hatto
bzw. bei mir passiert nicht ähnliches?
Kurzer Abriss bei mir: http://www.praast.de/hatto/
2 Frames, der linke benennt den rechten um und führt danach ein alert und
ein reload aus (jeweils auf den umbenannten Frame bezogen).
alert ergibt den neu vergebenen Namen (Änderung klappt laut NN6), der
darauffolgende Reload läuft aber über
top.oldName.location.reload()
Da meckert NN6, aber der IE führt den Reload durch! Selbst wenn der Frame
schon lange einen neuen Namen hat funktioniert der Reload über den alten
Namen (only IE).
Irgendwie hab ich das Gefühl, der verhaspelt sich irgendwo mit den laut
Frameset vergebenen Namen und den neuen Namen, ich bin jedenfalls nicht
durchgestiegen.
>Ist das ein IE 5.5 mit ServicePack 1?
IMHO nein.
>Hast Du eine Ahnung was die zwei optionalen Buchstaben am Ende bedeuten?
Nein.
Best regards
Michael
Thomas Fischer
huhu
> Nein, dein Script hatte ich nicht getestet, aber macht das, was bei Hatto
> bzw. bei mir passiert nicht ähnliches?
Nein, zumindest nicht bei Dir. Das von dir beobachtete Verhalten ist IMHO
völlig korrekt.
Im top wird nur zum Zeitpunkt des Parsens des FRAME-Tags eine Property "rechts"
angelegt. Egal wie oft du das name-Attribut eines Frames veränderst, im top
bleibt EINE Property ("rechts") erhalten, die eine Referenz auf den ursprünglich
als "rechts" benannten Frame (== frames[1]) hält und es wird KEINE Property
top.maus automatisch erzeugt, nur weil Du top.rechts.name="maus" ausführst.
Hier ein ähnliches Beispiel:
document.write('<iframe name="iFrameA"></iframe>');
iFrameA.name ="iframeB"
alert(
"iFrameA.name: " +iFrameA.name
+"\niFrameB: " +self.iFrameB
+"\nframes[0].name: " +frames[0].name
);
Kannst du nochmal bitte mit meinem Script testen und das Ergebnis bekanntgeben
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Michael Praast
>IMHO völlig korrekt.
Du verwirrst mich.
>Im top wird nur zum Zeitpunkt des Parsens des FRAME-Tags eine Property
>"rechts" angelegt. Egal wie oft du das name-Attribut eines Frames
>veränderst, im top bleibt EINE Property ("rechts") erhalten, die eine
>Referenz auf den ursprünglich als "rechts" benannten Frame
Brrr!
Warum nimmt dann NN6 das top.rechts.location.reload() nicht an, wenn der
rechte Frame auf 'maus' umbenannt wurde?
Wer ist denn da nun buggy: IE, NN oder ich?
> Hier ein ähnliches Beispiel:
Mann Thomas, muss ich ja abpinseln, und das mit der Hand im Gips...
Ok, alert ergibt:
iframeA.name=iframeB
iframeB:undefined
frames[0].name:iframeB
Hoffe, es hilft irgendwie, langsam bin ich ob der Frames & Co etwas
verwirrt bei diesem Problem, zumal ich noch nie mit iframe gearbeitet
habe.
Best regards
Michael
Thomas Fischer
huhu,
> Du verwirrst mich.
%-)
> Warum nimmt dann NN6 das top.rechts.location.reload() nicht an, wenn der
> rechte Frame auf 'maus' umbenannt wurde?
Bug? - Nein, glaub ich nicht [tm]
Mein Mozilla-Derivat "Beonex" macht es genau identisch wie NN4 und IE4:
Mach doch mal _EXACT_ folgendes:
Das Framset:
<html>
<frameset cols="*,*" frameborder="1">
<frame name="links" src="about:blank">
<frame name="rechts" src="about:blank">
</frameset>
</html>
Der Test (via Adress-Bar)
javascript:alert(top.rechts.name)
==> "rechts"
javascript:void(top.rechts.name="maus");alert(top.rechts.name)
==> "maus"
^^^^^^^^^^
> Wer ist denn da nun buggy: IE, NN oder ich?
^^^
> Mann Thomas, muss ich ja abpinseln, und das mit der Hand im Gips...
Oops, sorry, daß wußt' ich nicht! Hast du einen Bankräuber mit
Karateschlag ...
*duck*
> Ok, alert ergibt:
> iframeA.name=iframeB
> iframeB:undefined
> frames[0].name:iframeB
Dann ist der auch IMHO nicht buggy!
> Hoffe, es hilft irgendwie, langsam bin ich ob der Frames & Co etwas
> verwirrt bei diesem Problem, zumal ich noch nie mit iframe gearbeitet
> habe.
Der Hatto-Bug [tm] tritt auch IMHO nicht bei (i)Frames auf sondern nur
bei <a target="name" ...>
Gute Besserung!
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Michael Praast
>>der rechte Frame auf 'maus' umbenannt wurde?
>
>Bug? - Nein, glaub ich nicht [tm]
Dann erklärs mir bitte, warum ich da nur einen JS-error kriege, wenn ich
den grad auf 'maus' umbenannten Frame nicht mehr per 'rechts' ansprechen
kann. Ich dachte, NN machts richtig.
>Mein Mozilla-Derivat "Beonex" macht es genau identisch wie NN4 und IE4:
Seufz. Ist der Win-NN etwa anders?
Er liefert beide Male 'rechts'!
>Mach doch mal _EXACT_ folgendes:
~~~~~~~
Ja Vati. ;-)
> Der Test (via Adress-Bar)
Im IE dein Ergebnis. Im NN beide Male 'rechts' als Ergebnis.
Schön. nun weiß ich garnicht mehr, wos lang geht.
Aber wen wundert das, nach dem, was das Jahr 2000 bisher an
Überraschungen für mich parat hatte. Könnten wir das Problem nach 2001
vertagen?
>>Wer ist denn da nun buggy: IE, NN oder ich?
> ^^^
Ich habs geahnt. Wo kann ich nun Bugreports abliefern? Meine eltern
kannst du ausschließen, die leben seit diesem Jahr nicht mehr.
>Oops, sorry, daß wußt' ich nicht! Hast du einen Bankräuber mit
>Karateschlag ...
Nene, einfacher Unfall.
>>Ok, alert ergibt: [...]
>
>Dann ist der auch IMHO nicht buggy!
Grmmpf. Ok, nun kapier ich garnichts mehr.
>Gute Besserung!
Wenn ich nun noch wüßte, ob du das auf meine Flosse oder meine derzeitige
Verwirrung beziehst... ;-)
Best regards
Michael
Thomas Fischer
>
> Dann erklärs mir bitte, warum ich da nur einen JS-error kriege, wenn ich
> den grad auf 'maus' umbenannten Frame nicht mehr per 'rechts' ansprechen
> kann. Ich dachte, NN machts richtig.
mea culpa ... ich gebe zu, ich hatte es nur mit IE und Mozilla getestet,
NN deleted da wirklich die Referenz "rechts" ...
> > Der Test (via Adress-Bar)
>
> Im IE dein Ergebnis. Im NN beide Male 'rechts' als Ergebnis.
Hm, das versteh ich nicht! Ich erhalte beim zweiten Eintrag:
JavaScript Error:
top.rechts has no properties.
Da er ja "rechts" deleted hat ...
> Ich habs geahnt. Wo kann ich nun Bugreports abliefern? Meine eltern
> kannst du ausschließen, die leben seit diesem Jahr nicht mehr.
Scheint wirklich ein besch... Jahr zu sein, bin seit 3 Wochen "Halbwaise"
und wir sind ja noch gar nicht in dem Alter ...
> >Dann ist der auch IMHO nicht buggy!
>
> Grmmpf. Ok, nun kapier ich garnichts mehr.
Wenn das stimmt, das Du im NN4 beide male "rechts" bekommst ich auch nicht
mehr
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Michael Praast
"Thomas Fischer" <thomas....@tool42.com> schrieb:
>Michael Praast <mic...@praast.de> schrieb:
>>Im IE dein Ergebnis. Im NN beide Male 'rechts' als Ergebnis.
>
>Hm, das versteh ich nicht! Ich erhalte beim zweiten Eintrag:
>
> JavaScript Error:
> top.rechts has no properties.
>
>Da er ja "rechts" deleted hat ...
Nur zur Sicherheit (da ich mich da gestern wohl verhauen habe):
NN4.x: rechts / top.rechts has no properties
NN6.0: rechts / maus
IE5.5: rechts / maus
>Wenn das stimmt, das Du im NN4 beide male "rechts" bekommst ich
>auch nicht mehr
Damit ist nun deine Verwirrung beseitigt.
Was mich stutzig macht, dass sowohl IE5.5 als auch NN6 noch per
top.rechts... zugreifen können und keine Fehler liefern. Sind die beiden
jetzt buggy? Rein vom logischen her würde ich eher den 4er-NNs Recht
geben.
Best regards
Michael
PS: Hat jemand eine Idee, wie man die JS-Konsole permanent scharf machen
kann, ähnlich wie beim 4er?
Thomas Fischer
>
> Wenn das stimmt, das Du im NN4 beide male "rechts" bekommst
> ich auch nicht mehr
Ich habe jetzt (damit keiner mehr tippen muss) einen Test für
window.name online gestellt:
http://cookiejar.team42.net/tf/freestuff/nametest/
Ich bitte Euch die Seite mal aufzurufen, und das Formular zu senden.
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Georg Maaß
javascript:alert(rechts.name='hallo'); // umtaufen
javascript:alert(rechts.name); // nachsehen
--> rechts is not defined.
javascript:alert(hallo.name); // nachsehen
=> hallo
Ist es da, worüber Ihr Euch dauernd den Kopf zerbrecht?
Gruß, Georg
Thomas Fischer
>
> Was mich stutzig macht, dass sowohl IE5.5 als auch NN6 noch per
> top.rechts... zugreifen können und keine Fehler liefern. Sind die beiden
> jetzt buggy? Rein vom logischen her würde ich eher den 4er-NNs Recht
> geben.
Ich hab mal weiter rumgetestet:
<html>
<script type="text/javascript" language="JavaScript1.2">
function check(){
aOld.name="aNew";
frames[1].name="bNew";
document.write("<pre>"
+"aOld\taNew\tbOld\tbNew\n"
+!!self.aOld +"\t" +!!self.aNew +"\t"
+!!self.bOld +"\t" +!!self.bNew +"</pre>"
);
document.close();
};
</script>
<frameset cols="*,*" frameborder="1" onload="check()">
<frame name="aOld" src="">
<frame name="bOld" src="">
</frameset>
</html>
Ergebnisse:
===========
aOld aNew bOld bNew
IE true false true false
NN4 false true false true
Moz. true true false true
Erklärung:
==========
IE: legt nur beim Parsen eine Property im window-Objekt an
NN4: legt bei jeder Umbenennung eine neue Property an und
loescht immer die alte Property
(was bei aOld.name ="aNew" eigentlich nicht passieren darf)
Moz: legt bei jeder Umbenennung eine neue Property an und
loescht die alte Property, wenn bei der Umbenennung die
alte Property nicht zur Referenzierung benutzt wurde
Vielleicht findet ja jemand die W3C-Empfehlung, wie es nun richtig
sein sollte, ich finde es jedenfalls eigenartig, das ein simples
umdefinieren einer Objekt-Property plötzlich die Objekt-Referenz
flöten geht. Aber es ist ja schon problematisch, daß window==frames
ist ...
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Georg Maaß
> Aber es ist ja schon problematisch, daß window==frames
> ist ...
Hä? Wo passiert denn das? Das sind doch zwei völlig unterschiedliche Objekte,
wie können die gleich sein?
Grübel, Georg
--
Georg Maaß - bioshop.de, Sievekingsallee 35, D-20535 Hamburg
JavaScript-Engineering, http://www.bioshop.de/
Sherlock-Plugin: http://www.bioshop.de/Search/bioshop.bilder.src.hqx
Thomas Fischer
>
> > Aber es ist ja schon problematisch, daß window==frames
> > ist ...
>
> Hä? Wo passiert denn das? Das sind doch zwei völlig unterschiedliche
> Objekte, wie können die gleich sein?
Bei NN4.x und IE4+ sind sie nicht nur gleich sondern auch identisch.
bei Opera5 und NN6 sind sie ungleich.
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Georg Maaß
>
> Bei NN4.x und IE4+ sind sie nicht nur gleich sondern auch identisch.
Du meinst, window[0] und frames[0] ist identisch? <Ausprobier>
Tatsächlich. Daher kommen also die Probleme, wenn ich einen Frame scroll
nenne. Der ist dann nämlich bei MSIE nicht über seinen Namen
ansprechbar, weil MSIE es nicht zuläßt, daß ich die scroll-Methode
überschreibe. Jetzt verstehe erst, warum nicht nur parent.scroll nicht
funzt, sondern auch parent.frames.scroll.
Da muß man erst mal drauf kommmen, daß die da so einen Mist machen. Was
können da die NN und die M$-Leute mißverstanden haben, daß sie beide den
selben Bug implementierten, denn das dürfen nicht gleiche Objekte sein,
allein schon deshalb, weil es völlig verschiedene Objekttypen sein
müssen (Fenster <--> Collection von Fensterrefrenzen)?
Kopfschüttelnd, Georg
Hatto von Hatzfeld
> Thomas Fischer schrieb:
>>
>> Wenn das stimmt, das Du im NN4 beide male "rechts" bekommst
>> ich auch nicht mehr
>
> Ich habe jetzt (damit keiner mehr tippen muss) einen Test für
> window.name online gestellt:
> http://cookiejar.team42.net/tf/freestuff/nametest/
>
> Ich bitte Euch die Seite mal aufzurufen, und das Formular zu senden.
Gut, dann bekommst Du ja eine Übersicht, welche Browser betroffen sind.
Das ist sicher interessant (z.B. für Deinem Bugreport...).
Mich interessiert noch immer, was genau da passiert. Zu diesem Zweck
habe ich eine wesentlich weniger automatisierte Testseite erstellt:
http://www.salesianer.de/util/wnameself.html
wo man aber alles Mögliche selbst probieren, per Hand mit verschiedenen
Methoden (window.open, target in form, target in Link) Fenster aufrufen
bzw. ein Dokument dort hineinladen kann.
Mittlerweile habe ich auch einen MSIE 5.5 und konnte folgende
Feststellungen treffen, wobei ich jetzt mit "Öffnungsname" denjenigen
(nichtleeren) Namen meine, der in der Erschaffung/Öffnung eines Fensters
diesem zugewiesen wurde (egal, ob mittels eines bisher nicht existenten
targets in einem Link oder Form oder mittels window.open und einem
bisher nicht existenten Namen als 2. Parameter):
1. window.name kann durch Scripts geändert werden; beim Entladen wird
window.name jedoch auf den Öffnungsnamen zurückgesetzt (falls existent).
2. Der Augenblick dieses Geschehens liegt in der Nähe des onunload; es
liegt an davon unabhängigen Timing-Fragen, wann genau. Selbst bei einem
Link mit (per Javascript gesetztem) target auf den (zuvor ebenfalls per
Javascript gesetzten) neuen Namen habe ich beobachtet, dass schon
beim onunload der alte Name wieder hergestellt war (wohl gemerkt: das
muss nicht so sein; es ist mal so und mal anders!).
3. Der Gedanke, dass die "Dauerhaftigkeit" der Namenszuweisung davon
abhängt, ob der Name per HTML oder Javascript gesetzt wird, scheint
nicht der Realität zu entsprechen. Denn erstens ist beim Öffnen per
window.open der Öffnungsname ebenso unausrottbar wie bei Öffnen per Link
mit target, und zweitens wirkt sich nach der Zuweisung eines neuen
Namens ein Link mit target keineswegs stabilisierend auf den Namen aus
(siehe Punkt 4).
4. Der angedachte Workaround, nach einer Zuweisung an window.name per
target das nächste Dokument zu laden, funktioniert nicht (window.name
wird dann trotzdem durch den Öffnungsnamen ersetzt, falls existent.)
Frames habe ich für diese Versuche nicht benutzt; die Angaben beziehen
sich folglich immer auf den Namen des Browserfensters selbst.
Soweit die traurige Bilanz. Sieht irgendjemand Licht? Oder kann man die
Wertübergabe per window.name beerdigen?
Ciao,
Hatto
--
Um Rekursion zu verstehen, muss man zunächst Rekursion verstehen.
Rudolf "/dev/random" Polzer
news:3A3645D0...@bioshop.de...
> Ich habe folgendes unter Linux mit NN4.7 getestet:
>
> javascript:alert(rechts.name='hallo'); // umtaufen
> javascript:alert(rechts.name); // nachsehen
> --> rechts is not defined.
> javascript:alert(hallo.name); // nachsehen
> => hallo
>
> Ist es da, worüber Ihr Euch dauernd den Kopf zerbrecht?
Wieso, das sieht doch korrekt aus!
Rudolf "/dev/random" Polzer
news:912fsb$ams$03$1...@news.t-online.com...
IE 5.5: der Name lässt sich ändern.
Wolfgang Schwarz
-
Hatto von Hatzfeld wrote:
> Soweit die traurige Bilanz. Sieht irgendjemand Licht? Oder kann man die
> Wertübergabe per window.name beerdigen?
ich hab, mangels IE5.5, die Diskussion nicht genau verfolgt. Wollte nur
darauf hinweisen, dass IE fuer aeusserste Notfaelle (wie bei Thomas)
eine Alternative zur window.name-Technik hat:
function store(txt, id){
document.body.style.behavior="url(#default#userdata)";
document.body.setAttribute("saved", txt);
document.body.save(id);
}
function retrieve(id){
document.body.style.behavior="url(#default#userdata)";
document.body.load(id);
return document.body.getAttribute("saved");
}
Groesster Nachteil: Das funktioniert nur, wenn schreibende und lesende
Datei im selben Verzeichnis liegen. (Dabei gilt die URL des Dokuments,
nicht des Skripts.)
Brachialer workaround:
function store(txt, id){
document.body.insertAdjacentHTML("beforeEnd",
'<iframe name="speicherframe" style="display:none"
src="/404.html"></iframe>');
frames.speicherframe.document.body.style.behavior="url(#default#userdata)";
frames.speicherframe.document.body.setAttribute("saved", txt);
frames.speicherframe.document.body.save(id);
}
function retrieve(id){
document.body.insertAdjacentHTML("beforeEnd",
'<iframe name="speicherframe" style="display:none"
src="/404.html"></iframe>');
frames.speicherframe.document.body.style.behavior="url(#default#userdata)";
frames.speicherframe.document.body.load(id);
return frames.speicherframe.document.body.getAttribute("saved");
}
nicht so schoen, ich weiss. Vielleicht koennt ihr ja window.name doch
noch retten...
Wo.
Georg Maaß
> nicht so schoen, ich weiss. Vielleicht koennt ihr ja window.name doch
> noch retten...
Ist da jetzt einen neue Art Kekse ohne Cookies zu machen?
Gruß, Georg
Rudolf Polzer
georg...@gmx.de wrote:
> Wolfgang Schwarz wrote:
>
> > nicht so schoen, ich weiss. Vielleicht koennt ihr ja window.name
doch
> > noch retten...
>
> Ist da jetzt einen neue Art Kekse ohne Cookies zu machen?
Nicht wirklich. Denn ein window.name krümelt mir nicht die Platte voll.
Sent via Deja.com
http://www.deja.com/
Thomas Fischer
Es geht so, noch waren recht wenige auf der Seite. Deswegen nochmal die
Bitte an alle IE 5.5 Besitzer:
http://cookiejar.team42.net/tf/freestuff/nametest/
> Das ist sicher interessant (z.B. für Deinem Bugreport...).
Bis jetzt sind folgende IEs als buggy gemeldet:
5.50.4134.0600
5.50.4134.0600IC
5.50.4522.1800
5.50.4522.1800CO
5.50.4522.1800IC
Es scheint also, das nicht erst ab SP1 alle 5.5er betroffen sind ...
> Mich interessiert noch immer, was genau da passiert. Zu diesem Zweck
> habe ich eine wesentlich weniger automatisierte Testseite erstellt:
> http://www.salesianer.de/util/wnameself.html
Die aussage "Umbenennung in 'blafasel' erfolgreich." ist nur die halbe
Wahrheit. Die Property window.name ist zwar umbenannt, aber ein
<a href="javascript:alert(name)">name?</a>
gibt dir wieder den alten Namen zurück.
> 1. window.name kann durch Scripts geändert werden; beim Entladen wird
> window.name jedoch auf den Öffnungsnamen zurückgesetzt (falls existent).
NACK, nicht erst beim Entladen!
<a href="javascript:alert(name)">name?</a>
... bringt Dir zu jederzeit den alten Namen
> 2. Der Augenblick dieses Geschehens liegt in der Nähe des onunload;
NACK, s.o., scheinbar sobald das location-Objekt eine Zuweisung
erhält. Von außen gesehen (opener) ist das Fenster mittels des
neuen namens ansprechbar(open/target), allerdings auch nur solange
bis sich das location-Objekt ändert, dann ist es wieder unter dem
alten Namen anprechbar.
> 3. Der Gedanke, dass die "Dauerhaftigkeit" der Namenszuweisung davon
> abhängt, ob der Name per HTML oder Javascript gesetzt wird, scheint
> nicht der Realität zu entsprechen.
ACK
> Frames habe ich für diese Versuche nicht benutzt; die Angaben beziehen
> sich folglich immer auf den Namen des Browserfensters selbst.
Frames sind - wenn ich keinen Fehler im Test-Script gemacht habe - nicht
betroffen.
> Soweit die traurige Bilanz. Sieht irgendjemand Licht? Oder kann man die
> Wertübergabe per window.name beerdigen?
Mmh, die userdata-Geschichte muß ich mir nochmal anschauen ob die von
den Browser-Optionen geblockt werden kann - das wäre dann furchtbar ...
und dann hoff ich noch auf MS, daß die das als neuen und zu fixenden Bug
aktzeptieren, denn in http://msdn.microsoft.com/bugs/ ist nichts zu finden
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Thomas Fischer
huhu,
> [...]
>
> Groesster Nachteil: Das funktioniert nur, wenn schreibende und lesende
> Datei im selben Verzeichnis liegen. (Dabei gilt die URL des Dokuments,
> nicht des Skripts.)
>
> Brachialer workaround:
> [...]
Mmh, der ist leider nicht "brachial" genug :-(
- der body im iFrame ist nicht sofort da, sondern erst "irgendwann",
so daß read/write userdata nur asynchron laufen kann
- will man (wie ich es benötige) bei onunload Daten sichern, ist der
Versuch zum Scheitern verurteilt, da das Haupt-Dokument schneller
abgebaut ist als der iFrame geladen und somit den Weg alles irdischens
(garbage collection) nimmt.
- laufen mehrere Browserinstanzen/Frames, greifen alle auf die gleichen
Daten zu, so daß fensterbezogene Daten nicht mehr gesichert werden können
> nicht so schoen, ich weiss. Vielleicht koennt ihr ja window.name doch
> noch retten...
Ich werd mal bei der UNO nachfragen, hattest Du nicht einen guten Draht zu
Greenpeace? %-/
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Wolfgang Schwarz
Hallo Thomas,
Thomas Fischer wrote:
> - will man (wie ich es benötige) bei onunload Daten sichern, ist der
> Versuch zum Scheitern verurteilt, da das Haupt-Dokument schneller
> abgebaut ist als der iFrame geladen und somit den Weg alles irdischens
> (garbage collection) nimmt.
onbeforeunload gehts auch nicht? Sonst muesstest du den iframe eben
schon bei onload basteln (und nach dem Speichern gleich wieder
zerstoeren).
Hab gerade nochmal rumprobiert, aber ohne Erfolg. Die userdata-Methoden
kann man nur aufrufen, wenn sie an einem irgendwo integrierten
DOM-Element haengen. Wenn das Dokument ganz per document.write aufgebaut
wird, treten allerlei Fehler auf. Insbesondere ist es anscheinend
unmoeglich, in einem per document.write aufgebauten Dokument etwas zu
lesen, was man in einem anderen per document.write aufgebauten Dokument
geschrieben hat.
> - laufen mehrere Browserinstanzen/Frames, greifen alle auf die gleichen
> Daten zu, so daß fensterbezogene Daten nicht mehr gesichert werden können
Du kannst doch verschiedene IDs benutzen.
> > nicht so schoen, ich weiss. Vielleicht koennt ihr ja window.name doch
> > noch retten...
>
> Ich werd mal bei der UNO nachfragen, hattest Du nicht einen guten Draht zu
> Greenpeace? %-/
klar, ich hab schon Planungen eingeleitet. Wenn alles klappt, werden
demnaechst an allen Schornsteinen grosse Plakate mit der Aufschrift
"Rettet window.name!" haengen. :-)
Besser waeren natuerlich Kontakte zu einem gewissen G. Bush, seines
Zeichens politischer Arm der Microsoft-, Waffen- und Zigarettenlobby,
aber die muss ich erst noch aufbauen...
wo.
Hatto von Hatzfeld
>> habe ich eine wesentlich weniger automatisierte Testseite erstellt:
>> http://www.salesianer.de/util/wnameself.html
>
> Die aussage "Umbenennung in 'blafasel' erfolgreich." ist nur die halbe
> Wahrheit. Die Property window.name ist zwar umbenannt, aber ein
> <a href="javascript:alert(name)">name?</a>
> gibt dir wieder den alten Namen zurück.
Ich habe die o.g. Seite etwas ergänzt und festgestellt: Nur wenn ich es
so konstruiere, also in eine URL das "javascript:alert(name)" einbaue
(egal, ob Link oder Form), dann wird der alte Name zurückgegeben. Aber
er wird nicht nur dann zurückgeGEBEN, sondern der Name wird damit auch
auf den alten Wert zurückgeSETZT. Das sind dann so aus: Anzeige nach
onclick - neuer Name. Anzeige nach href="javascript:...." - alter Name.
Erneuter Aufruf mit onclick - alter Name.
IMO zeigt das, dass es sich wirklich um einen Bug handelt, und nicht um
Absicht.
Nun lässt sich auch ein relativ einfacher Test konstruieren, ob der Bug
sich gerade auswirkt: Ich ändere window.name, submitte ein Formular,
dessen action nur ein javascript:void(...) ist, mit dem geprüft wird, ob
der Name noch der neue ist. Falls nicht, dann kann ich z.B. ein neues,
namenloses Fenster öffnen, wo meine Scripts, die window.name benötigen,
auch problemlos laufen. Die Seite
http://www.salesianer.de/util/wertuebergabe.html
habe ich jetzt entsprechend ergänzt. Das ist IMO eine tragbare Lösung,
weil es relativ selten vorkommt, dass Browserfenster solche renitenten
Namen haben und der Autor der gerade besuchten Website nichts dafür
kann.
>> 2. Der Augenblick dieses Geschehens [...]
>
> [...] scheinbar sobald das location-Objekt eine Zuweisung erhält. Von
> außen gesehen (opener) ist das Fenster mittels des neuen namens
> ansprechbar(open/target), allerdings auch nur solange bis sich das
> location-Objekt ändert, dann ist es wieder unter dem alten Namen
> anprechbar.
Hm - jetzt merke ich erst, wir klar und luzide Du das erkannt hast...
Hätte ich genauer verstanden, was Du da geschrieben hast, wären meine
letzten Tests überflüssig gewesen :-)
> Mmh, die userdata-Geschichte muß ich mir nochmal anschauen ob die von
> den Browser-Optionen geblockt werden kann - das wäre dann furchtbar
Ich habe alles durchgesucht, alles blockiert, was zu blockieren war
(außer Scripting natürlich), und sie funktionierte immer noch.
Da ich auf das Problem gestoßen wurde, weil ein kommerzieller Internet-
Shop nicht mehr funktionierte, scheint mir die userdata-Geschichte zwar
prinzipiell eine Lösung (auch wenn mir nicht klar ist, warum MS da eine
anscheinend proprietäre Alternative zu Cookies geschaffen hat), kann
aber oft nicht einfach zur Reparatur verwendet werden, weil sie ja nur
zwischen Dokumenten desselben Verzeichnisses funktioniert.
> ... und dann hoff ich noch auf MS, daß die das als neuen und zu
> fixenden Bug aktzeptieren, denn in http://msdn.microsoft.com/bugs/ ist
> nichts zu finden
Also, wenn das kein Bug ist...
Ciao,
Hatto
--
Bewahre mich davor zu wissen, was ich nicht wissen muss. Bewahre mich
davor, auch nur zu wissen, dass es Wissenswertes gibt, von dem ich nichts
weiß. Bewahre mich davor zu wissen, dass ich beschlossen habe, nichts
von den Dingen zu wissen, die nicht zu wissen ich beschlossen habe. Amen.
Michael Praast
>so konstruiere, also in eine URL das "javascript:alert(name)" einbaue
>(egal, ob Link oder Form), dann wird der alte Name zurückgegeben. Aber
>er wird nicht nur dann zurückgeGEBEN, sondern der Name wird damit auch
>auf den alten Wert zurückgeSETZT.
Du bist dir da 100% sicher und hast das auf meiner Frametestseite
(grauenhaftes Wort) gegengetestet? Wo ist da ein Fehler im Aufbau (würd
mich ja nicht wundern)?
>Hm - jetzt merke ich erst, wir klar und luzide Du das erkannt hast...
>Hätte ich genauer verstanden, was Du da geschrieben hast, wären meine
>letzten Tests überflüssig gewesen :-)
Genau ab dem Punkt seid ihr mir wieder weit voraus. Hatte ich zu lange
JS-Abstinenz? Erklär mir mal bitte per PM, wo da mein Hänger ist.
Das erste Mal, dass ich mich auf eine Sig beziehe:
>Bewahre mich davor zu wissen, [...]
Ack.
Diesmal bin ich echt mehr als verwirrt. Könnte jemand Licht ins Dunkel
tragen?
Adventliche Grüße
Michael
Hatto von Hatzfeld
> "Hatto von Hatzfeld" <ha...@salesianer.de> schrieb:
>>Ich habe die o.g. Seite etwas ergänzt und festgestellt: Nur wenn ich es
>>so konstruiere, also in eine URL das "javascript:alert(name)" einbaue
>>(egal, ob Link oder Form), dann wird der alte Name zurückgegeben. Aber
>>er wird nicht nur dann zurückgeGEBEN, sondern der Name wird damit auch
>>auf den alten Wert zurückgeSETZT.
>
> Du bist dir da 100% sicher
Hm - eigentlich nur 99%ig. :-)
> und hast das auf meiner Frametestseite (grauenhaftes Wort)
> gegengetestet? Wo ist da ein Fehler im Aufbau (würd mich ja nicht
> wundern)?
Nein, habe ich nicht getestet. Aber, wie wir festgestellt haben, tritt
der Effekt ja auch nur beim name des top-Fensters auf.
>>Hm - jetzt merke ich erst, wir klar und luzide Du das erkannt hast...
>>Hätte ich genauer verstanden, was Du da geschrieben hast, wären meine
>>letzten Tests überflüssig gewesen :-)
>
> Genau ab dem Punkt seid ihr mir wieder weit voraus. Hatte ich zu lange
> JS-Abstinenz? Erklär mir mal bitte per PM, wo da mein Hänger ist.
Ich versuche mal eine Zusammenfassung:
Das hier diskutierte Problem mit window.name im MSIE 5.5 tritt dann auf,
wenn das betreffende Browserfenster (echtes Fenster, kein Frame) beim
Vorgang des Öffnens einen (nichtleeren) Namen zugewiesen bekommen hat
(egal, ob per target="..." oder per window.open()). Es äußert sich
darin, dass eine spätere Änderung von window.name (gemeint ist die
Eigenschaft name des mit top identischen windows) durch Zugriff auf die
location (z.B. durch Ausführung eines Links oder auch durch window.open
mit Angabe des neuen Namens - anderes habe ich noch nicht getestet)
wieder rückgängig gemacht wird. Auch ein Link wie
<a href="javascript:void(...)">...</a>
löst dieses Rücksetzen schon aus.
> Diesmal bin ich echt mehr als verwirrt. Könnte jemand Licht ins Dunkel
> tragen?
"Das Volk, das im Dunkel lebt, sieht ein helles Licht; über denen die im
Land der Finsternis wohnen, strahlt ein Licht auf." (Jes 9,1)
> Adventliche Grüße
Ebenso,
Hatto
--
Treffen sich zwei Geraden. Sagt die eine:
"Beim nächsten Mal gibst du einen aus!"
Thomas Fischer
>
> onbeforeunload gehts auch nicht?
Nein, daß ist ja auch nur ein paar Millisekunden zuvor. Das Problem bleibt,
ich schreibe ein load (iframe src) und muss warten bis geladen oder das
Element da ist, in der Zeit kann aber das Hauptdokument bereits entladen sein
> Sonst muesstest du den iframe eben schon bei onload basteln (und nach dem
> Speichern gleich wieder zerstoeren
Das ginge nur, wenn ich es schaffen koennte, den iframe nicht in der frames-
collection auftauchen zu lassen, da ich sonst das "fremde" DOM zu stark
beeinflusse
> > - laufen mehrere Browserinstanzen/Frames, greifen alle auf die gleichen
> > Daten zu, so daß fensterbezogene Daten nicht mehr gesichert werden können
>
> Du kannst doch verschiedene IDs benutzen.
Ähm, und woher soll ich diese ID's nehmen? Du weißt doch, daß es nur ein
statisches Script für alle Pages gibt. Ich muesste also _wissen_ daß mein
Script einmal in dem einen, einmal in dem anderen aufgerufen wird ...
man koennte eine pseudo ID generieren aus der Position des Fensters und
seiner Größe, aber das währe reichlich "pseudo" und wäre nicht mehr praktikabel
sobald der Surfer sein Fenster ändert ...
> klar, ich hab schon Planungen eingeleitet. Wenn alles klappt, werden
> demnaechst an allen Schornsteinen grosse Plakate mit der Aufschrift
> "Rettet window.name!" haengen. :-)
Hoffentlich, glaubt dann die Öffentlichkeit nicht, es handelt sich um sowas
ähnliches wie "dot com", vielleicht ja doch noch ein paar ECMA/W3C-URLs dazu?
> Besser waeren natuerlich Kontakte zu einem gewissen G. Bush, seines
> Zeichens politischer Arm der Microsoft-, Waffen- und Zigarettenlobby,
> aber die muss ich erst noch aufbauen...
Nö, dann lieber doch ohne window.name weiterleben! Es gibt doch noch sowas
wie Moral und wer hat schon Lust sich von einem Henkersknecht helfen zu
lassen ...
salute
Thomas Fischer (derdreiviertelvorzwölfte)
Hatto von Hatzfeld
> sich gerade auswirkt: Ich ändere window.name, submitte ein Formular,
> dessen action nur ein javascript:void(...) ist, mit dem geprüft wird, ob
> der Name noch der neue ist. Falls nicht, dann kann ich z.B. ein neues,
> namenloses Fenster öffnen, wo meine Scripts, die window.name benötigen,
> auch problemlos laufen. Die Seite
> http://www.salesianer.de/util/wertuebergabe.html
> habe ich jetzt entsprechend ergänzt. Das ist IMO eine tragbare Lösung,
> weil es relativ selten vorkommt, dass Browserfenster solche renitenten
> Namen haben und der Autor der gerade besuchten Website nichts dafür
> kann.
Eine Ergänzung noch: Der Test ist noch einfacher so zu machen:
function testmswnamebug() {
var wnl=top.name.length;
top.name+="x";
top.location.href="javascript:void(testmsnamebugw("+wnl+"))";
}
function testmsnamebugw(len) {
if(len>top.name.length) alert("MSIE-win.name-Bug aufgetreten!");
else top.name=top.name.substring(0,len);
}
Welche Aktion dann zu unternehmen ist, ist dann die zweite Frage.
Die Seite http://www.salesianer.de/util/wertuebergabe.html habe ich
diesbezüglich so überarbeitet, dass per form mit target ein neues
Fenster geöffnet wird.
Grüße,
Hatto
--
Gott erschuf Himmel, Erde und den Energieerhaltungssatz,
und er sah, dass es gut war.
Wolfgang Schwarz
Thomas Fischer wrote:
>
> > Sonst muesstest du den iframe eben schon bei onload basteln (und nach dem
> > Speichern gleich wieder zerstoeren
>
> Das ginge nur, wenn ich es schaffen koennte, den iframe nicht in der frames-
> collection auftauchen zu lassen, da ich sonst das "fremde" DOM zu stark
> beeinflusse
deshalb meinte ich ja auch: ihn gleich wieder zerstoeren.
> > > - laufen mehrere Browserinstanzen/Frames, greifen alle auf die gleichen
> > > Daten zu, so daß fensterbezogene Daten nicht mehr gesichert werden können
> >
> > Du kannst doch verschiedene IDs benutzen.
>
> Ähm, und woher soll ich diese ID's nehmen?
> man koennte eine pseudo ID generieren aus der Position des Fensters und
> seiner Größe,
ja, an sowas dachte ich. Oder an window.name... :-)
Oder du nimmst als ID die URL des speichernden Dokuments, d.h. beim
ladenden Dokument die des Referrers.
Aber loesen wir die Probleme doch der Reihe nach. Hier erstmal eine
Loesung fuer die Timing- und DOM-Probleme:
erste Datei:
txt="blablabla"; // das wird gespeichert
onunload=function(){
document.body.insertAdjacentHTML("beforeEnd",
"<iframe id='ifr' src='/404.htm'></iframe>");
frames.ifr.document.execCommand("stop");
with (frames.ifr.document.documentElement){
style.behavior="url(#default#userdata)";
setAttribute("saved", txt);
save("id");
}
}
zweite Datei (muss dieselbe Domain haben, aber nicht dasselbe
Verzeichnis):
onload=function(){
document.body.insertAdjacentHTML("beforeEnd",
"<iframe id='ifr' src='/404.htm'></iframe>");
frames.ifr.document.execCommand("stop");
with (frames.ifr.document.documentElement){
style.behavior="url(#default#userdata)";
load("id");
saved=getAttribute("saved");
}
setTimeout('document.all.ifr.outerHTML=""',0);
alert("saved: "+saved);
}
mit IE5/win98 funktioniert das schon ganz huebsch.
Einziger Nachteil ist noch der setTimeout vor der Zerstoerung des
Iframes. D.h. dass direkt bei onload der Iframe im DOM noch auftaucht.
Erst nachdem onload abgearbeitet wurde, verschwindet er. Lasse ich das
setTimeout weg, bleibt IE im Ladezustand (Cursor mit Sanduhr und
rotierende IE-Kugel).
document.body.removeChild(ifr);
geht auch nicht. Da kommt der Fehler: "Schnittstelle nicht
unterstuetzt".
Uebrigens hab ich gefunden, wo IE die userdata-Sachen hinspeichert. Bei
mir auf win98 ist es
C:\windows\Anwendungsdaten\Microsoft\Internet Explorer\UserData
Hier liegen xml-Dateien die so heissen wie die uebergebene ID. Wie genau
da die Element-Eigenschaften und die URL gespeichert sind, hab ich nicht
gesehen. Hab's mir aber auch nicht naeher angeschaut.
Stets moralisch,
Wo.