Beiträge von A.J.

Bitte genauere Angaben.
Was heißt "nicht mehr sichtbar"?
Auf welcher Seite?

Zitat von bugcatcher

Ich glaub es gibt kein einziges MS-Produkt das sich an irgendeinen Standard (selbst wenn es das behauptet) richtig hält.

Besonders lustig ist das ganze immer dann, wenn sie sich an ihre eigenen Standards nicht halten, z.B.

Zitat

Directory
Offset# | Size | Purpose
[...]
3 | 1 | reserved, should be 0

Zitat

Although Microsoft's technical documentation states that this value must be zero, the icon encoder built into .NET (System.Drawing.Icon.Save) sets this value to 255.

http://en.wikipedia.org/wiki/ICO_%28ic…at%29#Directory

Oder du kannst auch diese Erweiterung nutzen:
https://addons.mozilla.org/en-US/firefox/addon/2489

Du kannst versuchen die ARIALUNI.TTF einfach nach C:\Windows\Fonts zu kopieren.
Normalerweise wird die Schriftart auch ohne die Windows-CD korrekt erkannt.
(Evtl. ist es jedoch notwendig den Computer neu zu starten...)

In diesem Fall ist a[i].href in Verbindung mit GM_openInTab() klar im Vorteil, da stimme ich dir zu.

Generell bevorzuge ich aber a[i].getAttribute() und a[i].setAttribute(), da dies für alle Attribute funktioniert (auch für neu erfundene*) und man IMHO bei komplexem Code bei diesen schneller erkennen kann, ob ein Attribut gelesen oder geschrieben wird.

Darauf bezog sich mein "Vor- und Nachteile" hauptsächlich; das eine ist in diesem speziellen Fall besser, das andere (wie schon gesagt, meiner Meinung nach, ein Anderer ist da evtl. grundsätzlich anderer Meinung) übersichtlicher.

(Auch ist el.getAttribute() DOM2-Standard; bei el.href bin ich mir nicht sicher, kann aber im MDC darüber auch nichts finden, ob es standardisiert wurde oder nicht)

Bezüglich der Tatsache, dass ich nochmals auf GM_openInTab() und window.open() zurückkam: Ich wollte nur zeigen, dass es bei window.open() egal ist was man verwendet, bei GM_openInTab() nicht. Wenn sich beide gleich verhielten, bräuchte man diese Überlegungen gar nicht, man könnte einfach immer beide (el.getAttribute + el.href) verwenden, da es egal wäre, ob eine relative oder absolute URL übergeben wird, da beides korrekt interpretiert werden würde.

Aber das ist etwas, was sowieso nur der Entwickler von Greasemonkey beeinflussen kann. Denn ich denke es wäre einfacher und logischer, wenn sich GM_openInTab() bezügl. relativen URLs und Referrer gleich verhalten würde wie window.open(). Allerdings weiß ich nicht wie schwierig es wäre dies in der Erweiterung umzusetzen...

-----
*Manche Webseiten (und Erweiterungen) tun dies tatsächlich. Und in speziellen Fällen muss man auch diese lesen+schreiben können.

Wenn ich window.open() verwende werden relative Links auch unmittelbar aufgelöst.

Im Detail:
window.open(a[i].getAttribute('href')) und window.open(a[i].href) funktionieren sowohl für relative als auch absolute Links.
GM_openInTab(a[i].getAttribute('href')) funktioniert nur für absolute Links (relative produzieren nur Müll).
GM_openInTab(a[i].href) funktioniert für absolute und relative Links.

Was lernen wir daraus?
Alle Methoden haben ihre Vor- und Nachteile.* UND: Viele Wege führen zum Ziel.

Desweiteren:
1) Bezügl. Portnummern: Portnummer werden nur sehr selten verwendet weshalb ich sie (bewusst) ignoriert habe. Wenn sie benötigt werden, wäre das Userscript jedoch jederzeit leicht erweiterbar.
2) Bezügl. file://-URIs: Diese werden je nach Browser und Betriebssystem verschieden gehandhabt und sind daher sowieso alles anderen als einheitlich / verlässlich.

------
*Auf weitere Vor- und Nachteile von window.open() <-> GM_openInTab() bin ich ja schon weiter oben eingegangen.

Zitat von milupo

Die Umlaute im title-Attribut sollten wohl doch maskiert werden (&auml; &ouml; &uuml;).

Müssen sie nicht. Es reicht aus wenn sie als UTF-8 eingebunden sind, wie der Rest des Dokuments. Dies geschieht aber scheinbar nicht korrekt.

Zitat

Im Quellcode hat der a-Tag, zu dem das title-Attribut gehört, die Stilklasse "wiki" zugewiesen bekommen, die es aber weder in der mozcommon.css noch in der mozkb.css gibt.

Völlig egal.

Zitat

Dann hatte ich gedacht, dass die font-family aus dem body-Tag eventuell das Problem darstellt (georgia, serif).

Tooltips verwenden die im Betriebssystem definierte Schriftart, es ist irrelevant welche die Seite für den "normalen" Text definiert.

Auf dieser Seite wird der Tooltip noch viel chaotischer angezeigt:
https://support.mozilla.com/de/kb/Anpassungen#Symbolleisten
[Blockierte Grafik: http://img301.imageshack.us/img301/6140/tooltipst2.th.png]

Ja, die Umlaute im Tooltip werden auch bei mir falsch dargestellt.

Zeichenkodierung ist UTF-8, ob die automatische Bestimmung an oder aus ist macht keinen Unterschied.

Wenn du das Problem mit allen Browsern hast, ist auf jeden Fall Firefox nicht schuld an dem Problem.
Verdächtig wäre ersteinmal Software, die den Netzwerkverkehr überwacht/beschränkt wie Virenscanner, Firewall, etc. ...

Ohne die Seite zu kennen, wird es immer schwieriger dir weiter zu helfen.

Nutzt die Seite javascript-Links oder wird sie durch Javascript dynamisch aufgebaut?
Erscheinen in der Fehlerkonsole (Extras->Fehlerkonsole) irgendwelche Meldungen?

Wenn das Greasemonkey-Script installiert wurde und URL bzw. Schlüsselwort korrekt eingetragen wurde, sollte es funktionieren, d.h. wenn du eine Seite besuchst, die dem unter URL eingetragenen Wert entspricht und sich auf der Seite Links befinden die das Schlüsselwort enthalten, sollten diese sofort in neuen Tabs geöffnet werden.
Du musst nichts noch irgendwie extra auslösen.

???

Zitat von boardraider

A.J. wrote:

Doch hat sie. [...]

In diesem Fall tatsächlich.

Ich hätte mir die Seite, bevor ich die Antwort verfasst habe, genauer anschauen sollen, denn ich bin davon ausgegangen, dass kein Server so schlecht konfiguriert ist, dass er einen Link der schon escaped wurde unescaped und dann dem Browser ohne Angabe von Zeichenkodierung zusendet...

Hier das Greasemonkey Script:

// ==UserScript==
// @name           Alle Links mit Schlüsselwort öffnen
// @namespace      http://www.w3.org/1999/xhtml 
// @include        URL
// ==/UserScript==


a = document.getElementsByTagName('a');


for (i = 0; i < a.length; i++) {
   if (a[i].getAttribute('href')) {
      if (a[i].textContent.indexOf('Schlüsselwort') != -1) {
         if(a[i].getAttribute('href').match(/.*:\/\/.*/)) {
            GM_openInTab(a[i].getAttribute('href'));
         }
         else {
            if(a[i].getAttribute('href').slice(0, 1) == "/") {
               GM_openInTab(document.location.protocol + "//" + document.location.hostname + a[i].getAttribute('href'));
            }
            else {
               GM_openInTab(document.location.protocol + "//" + document.location.hostname + document.location.pathname.match(/.*\//) + a[i].getAttribute('href'));
            }
         }
      }
   }
}

Anmerkungen:
URL (Zeile 4) muss durch die URL ersetzt werden, auf der das Userscript angewendet werden soll. Der Stern * ist Platzhalter für beliebige Zeichen, so würde http://www.example.com/* bedeuten: wende das Userscript auf http://www.example.com und auf allen Unterseiten an.

Schluesselwort (Zeile 11) muss durch das entsprechende Schlüsselwort ersetzt werden. Das Schlüsselwort muss in Hochkommata oder Anführungszeichen eingeschlossen sein.

Die einfachste Methode, das Userscript zu installieren, ist den gesamten Text in einen Texteditor zu kopieren, das ganze als irgendeinname.user.js zu speichern und diese Datei dann zum installieren auf das Firefox-Fenster zu ziehen oder per Datei->Öffnen zu öffnen...

Zitat von pittifox

Kann es daran liegen:
wie muß die Zeichencodierung bei: Automatisch bestimmen eingestellt sein?
Per Default steht sie auf: AUS
Ich hatte sie auf: Universell, ist das falsch?
[...]
Kann es dadurch bei einer Weiterleitung zu Problemen kommen wenn die Zeichencodierung bei Universell auf: AUS steht?

Glaube nicht, dass die im Browser eingestellte Zeichenkodierung hier einen Einfluss haben dürfte...

Zitat

Frage 2: wieso ist die Zeichencodierung im FF-Wiki auf : UTF-8 und nicht wie im Forum auf : westlich ISO- 8859-1

Mediawiki (die Wiki-Software) nutzt als Standard UTF-8
phpBB2 (die Foren-Software) nutzt als Standard ISO-8859-1
(nebenbei: phpBB3 nutzt auch UTF-8)

Zitat von MonztA

[...]womit nur nervige Werbung geblockt wird.

Was ist in diesem Fall "nervige Werbung"?
Im verlinkten Thread findet sich dazu keine genaue Definition...

Befindet sich das Schlüsselwort im Link-Text oder in der URL?

Zitat von boardraider

Falsch, Greasemonkey hat eine API über die man neue Tabs öffnen kann(...)

OK, diese API-Methode kannte nicht. (Liegt vermutlich daran, dass ich noch kein GM-Script geschrieben habe, dass einen neuen Tab öffnen sollte)

Allerdings hat GM_openInTab(URL) auch so seine Tücken, so funktioniert das nicht auf Seiten, die einen Referrer erwarten:

Zitat

Opening webpages by invoking this method may not be the ideal choice, because this method doesn't save the referring page, which makes webservers think that you are calling a page only by it's URL, and not from the webpage it was on. In the cases where it doesn't work, one may use window.open(url) instead, which is similar in that it opens a new tab, but it keeps the referrer and switches to the tab immediately.

http://wiki.greasespot.net/GM_openInTab

Generell stellt sich aber sowieso die Frage ob er die Tabs immer sofort öffnen lassen will (GM-Script besser geeignet), oder nach Bestätigung (beides geeignet).

Zitat von boardraider

Mit einem Bookmarklet kannst du i.d.R. keine neuen Tabs öffen, lediglich neue Fenster.

Jein, wenn ich von Firefox > 1.5 und Standardeinstellungen ausgehe,
dann erstellt window.open(URL) einen neuen Tab und kein neues Fenster.
(Wohingegen window.open(URL, parameter) ein (Popup-)Fenster öffnen würde.)

Desweiteren habe ich doch mit Greasemonkey auch keine andere Möglichkeit als window.open(...) um ein neues Fenster bzw. einen neuen Tab zu öffnen, oder?
(Da die Userscripte im Kontext der Webseite ausgeführt werden habe ich ja keinen Zugriff auf die Chrome-Funktionen, mit denen man sich 100%-sicher sein könnte, ob ein neues Fenster oder ein neuer Tab erstellt wird...)