esse est percipi
Das Weblog eines Grafikdesigners. Seit 2003.

esse est percipi

Einfach gute Mac-Apps.

Von einem unabhängigen Entwickler,
der sie täglich selbst nutzt.

Blog Apps

Impressum/Datenschutz/AGB

Digitale Welt | Dienstag, 19. April 2005

Safari 1.3 Bug

Seit Safari Version 1.3, die mit dem Update auf Mac OS X 10.3.9 installiert wurde, funktionieren named anchors im Zusammenhang mit einem querystring nicht mehr. Beispielsweise sollte dieser Link
/images/20050418-114434?com=1#kommentar
die entsprechende Seite laden und den Inhalt bis zum Anchor kommentar scrollen. Geladen wird die Seite, aber der Anchor wird ignoriert. Genauso wenig funktioniert übrigens
/images/20050418-114434#kommentar?com=1.

Wenn ich RFC2396 richtig verstehe, ist die Methode, den Fragment Identifier an das Ende des URI anzuhängen, die richtige.

7) The resulting URI components, including any inherited from the base URI, are recombined to give the absolute form of the URI reference. Using pseudocode, this would be

result = „“

if scheme is defined then
append scheme to result
append “:“ to result

if authority is defined then
append “//“ to result
append authority to result

append path to result

if query is defined then
append “?“ to result
append query to result

if fragment is defined then
append “#“ to result
append fragment to result

return result

Ich kann nur hoffen, dass dieser Bug in Safari 2.0 behoben ist, einstweilen kehre ich erst mal wieder zu Safari 1.2 zurück.

Update: Safari 1.3 Bug Teil 2

Safari

Kommentare:

Bei den Kommentaren handelt es sich um fremde Inhalte, die sich „esse est percipi“ nicht zueigen macht. Verantwortlich für den Inhalt eines Kommentars ist der jeweilige Verfasser.

anne Dienstag, 19. April 2005, 12:33 Uhr

das hat mit firefox aber auch nie wirklich exakt geklappt?

Hagen Dienstag, 19. April 2005, 12:47 Uhr

@anne: Wenn das nicht „exakt“ klappt, kann das am CSS liegen. Seiten in denen Tabellen enthalten sind (und sinngemäß verwendet werden) und die Größe oder Postionen einiger Elemente (oder auch der Tabellenfelder) via CSS definiert werden haben sowohl IE als auch Firefox Probleme mit dem genauen „anspringen“ solcher Anker. Aber das hat jetzt nix mit Safari zu tun :)

Michael Preidel Dienstag, 19. April 2005, 12:52 Uhr

Ich habe gerade noch mal getestet – mit Opera 6.03, Camino 0.8.2, Firefox 1.0 und Omniweb 5.1 (alle unter Mac OS X) gibt es keine Probleme, die springen alle brav zum Anker, so wie es Safari 1.2 auch getan hat.

Bastian Dienstag, 19. April 2005, 13:25 Uhr

Stimmt, habe eben geupdatet auf 10.3.9 und es geht gerad nicht mehr.
Das ja ein Mist….da sollten die lieber flott ein Safari Update hinterher schieben. Manche Seiten basieren ja auf den Ankern.

Björn Graf Dienstag, 19. April 2005, 13:51 Uhr

Nun, das name Attribute ist für Elemente ausser Form-Eingabe-Elementen (input et al.) als veraltet bezeichnet worden – nicht dass das die Sache in irgendeiner From entschuldigen würde, aber leere a Elemente haben mich schon immer gestört :]

Wiedemauchsei, der Versuch eines Workarounds wäre (ich ahbe leider keine Möglichkeit, es selbst zu testen), die aktuelle Form (hervorgehoben, weil aktuell im diesem Zusammenhang nicht unbedingt die allgemeine Benutzung wiederspiegelt :]) der Fragment Identifiere Ziele zu testen: das Ersetzen der name Attribute in (leeren) a Elementen durch id Attribute gleichen Inhalts in den eigentlichen Ziel Elementen.

anne Dienstag, 19. April 2005, 14:01 Uhr

@hagen/@michael:
steh ich wohl gerade aufm schlauch? ich frage mich ja nur, warum safari ein bug vorgeworfen wird, wenn das auch in firefox 1.0 nicht so genau klappt (ich spreche jetzt von den ankern auf qxm)—bei mir springt jedenfalls der browser nie an die stelle, die ich dem ankerlink entnehme wie zb
http://www.qxm.de/musik/20050418-114434#kommentar?com=1 = erster kommentar oder nicht? bei mir kommt dann aber nur der eintrag. auch bei den links in der sidebar komme ich einfach nur zum jeweiligen start der kommentarbereiche? und scrolle dann zum anvisierten kommentar.

Michael Preidel Dienstag, 19. April 2005, 14:20 Uhr

@ Björn: Ich habe <a name=“kommentar“></a> probeweise mit <div id=“kommentar“>test</div> ersetzt. Safari zeigt bei beiden Methoden das gleiche Verhalten: bin ich bereits auf der Seite, springt Safari den Anker bzw. das div an, muss Safari die Seite erst laden, wird nicht gesprungen. Das zeigt IMHO einigermaßen deutlich, dass der URI nicht richtig geparst wird.

@ Anne: Es gibt hier keine Anker für einzelne Kommentare, es wird grundsätzlich immer nur zum Anfang des Kommentarbereichs gesprungen. Und das funktioniert eben mit allen getesteten Browsern – bei mir auch mit Firefox – einwandfrei, mit Safari 1.3 hingegen nicht.

Danilo Dienstag, 19. April 2005, 16:05 Uhr

Auf der Seite http://www.w3.org/XML/Core/#Publications funktionierts problemlos.

Hier auch: http://thinkdrastic.de/asylum/think3/journal/#content

<a name=“kommentar“></a> eventuell durch <a div=“kommentar“></a> ersetzten?

Björn Graf Dienstag, 19. April 2005, 18:46 Uhr

@Michael: Ah, das Verhalten hab’ ich irgendwie überlesen :] Nur ist’s nicht unbedingt auf ein falsches parsen der URI zurückzuführen (sonst würde in-page Navigation auch nicht functionieren), sondern eher auf einen Fehler im internen onload handler, der für das korrekte Setzen von doc.scrollTop (oder wie auch immer man es nennen mag) zuständig ist. Anyway, ein (relative) unverzeilicher regressions Fehler in beiden Fällen :]

Zum Glück kommt Safari ja mit ‘nem Bug Report Button ;)

Michael Preidel Dienstag, 19. April 2005, 19:30 Uhr

@ Danilo: Das funktioniert bei mir auch – die URIs beinhalten ja aber auch keinen Querystring in der Art ?com=1.

@ Björn: Ja, den Bugreport hatte ich schon losgeschickt. Das, was du beschreibst, kann auch sein, was mich aber trotzdem eher an einen Parsingfehler glauben lässt, ist die Tatsache, dass Safari bei der In-Page Navigation offensichtlich alles außer dem Fragment Identifier aus dem URI entfernt, um die Seite nicht komplett neu zu laden.

Christian Dienstag, 19. April 2005, 20:58 Uhr

Gegenbeispiel: Auf MacRumors tut’s . Vielleicht doch CSS-Probleme?

Thiemo Dienstag, 19. April 2005, 22:04 Uhr

In der betreffenden Seite gibt es neben dem Sprungziel auch ein Formular sowie eine CSS-Klasse, die alle „kommentar“ heißen. Vieleicht verträgt sich das nicht?

Björn Graf Dienstag, 19. April 2005, 01:44 Uhr

Hm, nachdem Firefox sich weigerte, beim onload zu springen, der Trackbacks und Kommentare-link oben aber tat, was von ihm erwartet wurde, fiel mir ein kleiner unterschied auf: von externen Seiten ist dar Fragment Identifierer #com oder #kommentar, intern aber #kom...

Michael Preidel Mittwoch, 20. April 2005, 07:36 Uhr

Weil es bei dem Link von Christian (das sind übrigens die MacGuardians ;-) tatsächlich funktionierte, hatte ich nach Thiemos Anregung versuchsweise mal die Namen von Anchor und Identifier geändert, das brachte aber auch keine Änderung.

Und nachdem ich im Quelltext der MacGuardians-Seite auch nichts entdecken konnte, was sich irgendwie von meinem unterschied, bin ich, ohne den Ursprungszustand in meinen Scripten wieder herzustellen, schlafen gegangen.

Jetzt springen wieder alle Browser (auch Firefox), nur Safari 1.3 tut’s leider immer noch nicht.

Christian Mittwoch, 20. April 2005, 10:47 Uhr

Uppsa… da habe ich wohl die zwei Mac-Seiten miteinander verwechselt, die ich regelmäßig besuche ;-). Das ist wirklich seltsam. Ich habe zwischendurch eine andere, recht einfache Seite gesehen, wo’s ebenfalls nicht funktioniert (mit QueryString).

Übrigens, bei garageband.de im Forum sind die Avatare nun seltsam verrutscht/abgeschnitten—wohl auch ein Safari 1.3-Bug.

Sehr schade das, denn deutlicher schneller ist 1.3 schon, finde ich.