Ich finde ja, dass Automatisch / Universell voreingestellt sein sollte (bis vor Kurzem dachte ich, dies sei auch der Fall). Natürlich wissen wir alle, dass der Server die Seitencodierung mitsenden sollte. Wir wissen aber auch, dass viel zu viele Server das nicht tun.
Was spricht eigentlich gegen diese Option als Standard? Bei mir kommt es eigentlich nie zu Fehlerkennungen, dies kann also nicht der Grund sein.
Zitat von Mozillau.Wenn ich auf der Taskleiste klicke erscheinen mir immer Fenster mit weißem Hintergrud , zuvor waren sie aber grau?!
Wie kann ich das jetzt einstellen.
Keine Ahnung, was du damit meinst. Was bedeutet "zuvor", und von welchen Fenstern sprichst du?
Zitat von Mozillau.Bei Google erscheint mir wenn ich einen Begriff eingebe immer eine Liste mit Begriffen,die ich gesucht habe?!
Wie mache ich diese Liste nicht mehr vorhanden?!
Extras -> Einstellungen -> Datenschutz -> Haken entfernen bei Daten speichern, die in Formulare und Suchleisten eigegeben werden
Zitat von Mozillau.Pop up Fendster esceheinen nicht mehr in einer Leiste, sondern in der rechten Ecke von der Taskleite?!
Wie kann ic das ändern?!
Klicke auf das kleine Popup-Symbol in der Statusleiste und entferne den Haken bei Keine Informationsleiste einblenden, wenn Popups blockiert werden
Zitat von Mozillau.Bei Installieren wurde ich gefragt, ob ich die IE Einstellungen übernehmen möchte?!
Nein, das wurdest du nicht gefragt. Du wurdest gefragt, ob du die Lesezeichen vom IE übernehmen möchtest.
Zitat von Mozillau.Kann man das auch rückgängig machen?!
Ja. Wenn du die Lesezeichen übernommen hast, lösche sie einfach wieder. Wenn du sie nicht übernommen hast, Klicke auf Datei -> Importieren..., wähle dort die Option Microsoft Internet Explorer und folge den Anweisungen.
Dieser Parameter steht standardmäßig auf true, was bedeutet, dass Seiten das Kontextmenü ersetzen dürfen. Weil damit aber auch diese nervigen "Rechtsklickverhinderer" möglich sind, stellen viele Anwender dise Option auf false (oder sie stellen dies unter Extras -> Einstellungen -> Inhalt -> JavaScript -> Erweitert ein, die Option Das Kontextmenü zu deaktivieren oder ersetzen in diesem Dialog hat die gleiche Wirkung).
Es gibt einige wenige Seiten, die dieses Feature tatsächlich sinnvoll nutzen, z. B. die Oberflächen diverser Webmailer. Ich möchte es trotzdem nicht, wenn das Kontextmenü deaktiviert wird (was auch keinen Sinn hat, Inhalte schützen kann man damit nämlich nicht, was leider viele denken) und habe die Option deshalb auf false gestellt.
Mein Gott, wie peinlich... :oops:
Du hast natürlich Recht, wie man auch dem ersten Post in diesem Thread entnehmen kann. Vielen Dank für den Hinweis!
Also zweiter Versuch, 412306 habe ich mal ganz, ganz schnell als INVALID markiert.
Ich kann es leider nicht nachvollziehen. Zwar verwende ich kein PDF-Plugin, sondern lasse mir PDF-Dateien ganz normal zum Download anbieten wie jede andere Datei auch, aber das funktioniert bei mir Problemlos.
Die Links werden allerdings per JavaScript generiert. Hast du vielleicht NoScript oder etwas anderes installiert, was die Skripte stören oder blocken könnte?
Für diesen konkreten Fall kann ich dir die Direktlinks anbieten, falls du sie nicht selbst "gefunden" hast:
Bei Bedarf kannst du diese Dokumente hier mit Rechtsklick und Ziel speichern unter...auf die Festplatte speichern und lokal starten. Die Ursache deines Problem löst das aber natürlich nicht. Eventuell hilft es, wenn du den Adobe Reader mal neuinstallierst.
Das war mir bisher völlig unbekannt, scheint aber sehr interessant zu sein. Auch wenn ich kein Erweiterungs-Entwickler bin.
Ich musste mal wieder feststellen, dass Bugzilla nicht gerade einfach zu handhaben ist. Weder die Suche nach Duplikaten noch die Zuordnung des Problems zu einer Komponente würde ich bedienerfreundlich nennen. Es wundert mich nicht wirklich, dass trotz guten Willens immer wieder Duplikate gemeldet werden oder die Zuordnung nicht nachvollziehbar ist...
Wie auch immer: Hoffentlich liege ich mit Bug #412314 nicht vollkommen daneben.
Falls du Windows nutzt: Im Profilordner gibt es eine Datei formhistory.dat, dort werden die Einträge gespeichert. Du solltest diese Datei allerdings nicht direkt editieren. Besser ist es, unerwünschte Einträge mit der Maus (nicht klicken, nurdarauf zeigen!) oder den Cursor-Tasten auszuwählen und sie mit [Shift] + [Entf] zu entfernen.
Das ist mir schon klar :wink:
Aber gerade deswegen sollten ja jetzt gefundene Bugs gemeldet werden. Die Frage ist, ob sich Gekko hier standardkonform verhält oder ob es wirklich ein Fehler ist (und wenn ja, ob er evtl. schon bekannt ist).
Ich habe ein Problem mit der Seite http://www.gdp-foerderverein.de, die in absolut validem HTML geschrieben ist.
Bei einer Bildschirmauflösung von 1024x768 Pixel hat diese Seite eine vertikale Scrollleiste. IE 5 bis 7, Firefox 1.5.*, Firefox 2.0.*, Opera 6 bis 9, Safari 3 und Konqueror zeigen das Hintergrund rechts ausgerichtet und vollständig sichtbar an. In Firefox 3.0b2 allerdings beginnt das Hintergrundbild direkt am rechten Bildschirmrand und wird so von der Scrollbar teilweise verdeckt.
Ist das ein Bug in der Rendering-Engine? Ich kann mir nicht vorstellen, dass dieses Verhalten dem Standard entspricht, zumal ja andere, teilweise ebenfalls sehr standardtreue Browser es anders und wie ich finde wesentlich logischer anzeigen.
Also wie der DOM-Inspektor mir dabei helfen kann, konnte ich nicht herausfinden. Kann man damit auch Chrome-Bereiche analysieren?
Wie auch immer, ich habe den Verursacher gefunden: Es war RefSpoof und ich erinnere mich, dass diese Erweiterung schon beim Umstieg von 1.5 auf 2.0 erhebliche Kompatibilitätsprobleme hatte. Inzwischen gibt es da ja Alternativen (URLParams zum Beispiel), sodass ich darauf gut verzichten kann.
Zum produktiven Einsatz nehme ich sowieso auch weiterhin die 2.0.0.11. Meine Erweiterungen laufen zwar gut mit der 3.0b2, aber offiziell kompatibel sind ja erst recht wenige.
Ich habe gerade mal die 3.0b2 installiert und mit MR Tech Local Install bei allen Erweiterungen die Kompatibilität erzwungen. Das funktioniert ziemlich gut, bis auf folgendes kleine, aber nervige Problem: Beim Standardtheme wird über der Menüleiste eine zusätzliche Toolbar mit zwei Unicode-Symbolen dargestellt:
[Blockierte Grafik: http://downloads.pigsgrame.de/bilder/ff_menu3.jpg]
Weiß zufällig jemand, welche meiner Erweiterungen dieses Problem verursacht? Ich könnte mir dann die zeitraubende Suche nach dem Übeltäter sparen. Die Erweiterungen, die mir am verdächtigsten erschienen, nämlich Menu Editor und Quick Preference Button, sind es nicht.
Trotzdem: Fixe Layoutbreiten sind auch etwas, dessen Sinn ich nie begreifen werde. Das ist wieder etwas, wo Webmaster entscheiden, was die Anwender wollen. Das "Killerargument" für feste Breiten ist immer, dass man zu lange Zeilen schlecht lesen könne. Abgesehen davon, dass das nicht jeder so empfinden muss: Was hindert mich, wenn mich die zu große Zeilenlänge tatsächlich mal stört, daran, einfach das Fenster zu verkleinern? Ich brauche eigentlich niemanden, der dies für mich vornehmen will.
Je höher die benutzte Bildschirmauflösung ist, desto geringer wird die Wahrscheinlichkeit, dass ein Anwender im Vollbildmodus surft. Wenn er es aber tut, dann wird er in der Regel auch erwarten, dass die angezeigten Webseiten das beachten und nicht nur 800 Pixel breit sind. Einige Webmaster trauen dem Anwender aber einfach nicht zu, bestimmte Entscheidungen selbst treffen zu können. Die hier schon erwähnten Popups, die nicht in der Größe veränderbar sind, fallen in die gleiche Kategorie.
Der folgende Beitrag wurde von yoshiowl wieder entfernt. Ich zitiere ihn hier nochmal, sonst ist mein Post aus dem Zusammenhang gerissen:
Zitat von yoshiowlIst ja richtig!
aber FF Verlangt ja die <embed> angabe im html (xhtml)
Nochmals, ich möchte, das der FF .swf darstellt OHNE das man in seinem (x)html das <embed> benutzen muss.
So wie es eben ALLE adneren aktuellen Browser auch machen.
Dieser blöde Nicht Valide <embed> ist doch noch aus Netscape zeiten......
OK, FF bez. Mozila ist ja n ableger davon.
---
Zitat von yoshiowlNochmals, ich möchte, das der FF .swf darstellt OHNE das man in seinem (x)html das <embed> benutzen muss.
Nochmals? Also entschuldige, aber deine bisherigen Beiträge konnte ich beim besten Willen nicht dahingehend deuten.
Es ist kein Problem, Flash-Objekte ohne <embed> einzubinden: Wie ich bereits sagte: Alle modernen Browser kommen ohne <embed> aus, und auf Netscape 4, der auf Standardunterstützung wirklich gesch!ssen hat, braucht man heutzutage keine Rücksicht mehr zu nehmen. Zur Kompatibilitätssicherung interpretieren alle modernen Browser veraltete, ungültige aber dennoch häufig benutze Code-Kontrukte, eben z. B. auch die nicht valide <embed>-Konstruktion. Es ist aber falsch, dass der Firefox den <embed>-Tag benötigt. Wenn er vorhanden ist, interpretiert Firefox ihn, obwohl er nicht standardkonform ist, weil viele Webdesigner ihn fälschlicherweise nutzen.
Schau dir nur mal als Beispiel diese Seite an. Sie ist zwar HTML 4.01 Strict und kein XHTML 1.0 Strict, aber sie zeigt dir trotzdem, wie man Flashobjekte ohne <embed> einbinden kann, und zwar so, dass es der Firefox und alle anderen modernen Browser korrekt interpretieren. Das Grundgerüst in XHTML sieht dafür so aus:
<!-- Anstelle von ... die Adresse der Flash-Datei einsetzen -->
<object type='application/x-shockwave-flash' data="...">
<param name="movie" value="..." />
</object>Zitat von yoshiowlMuss man denn jetzt wirklich wieder mit nem IE7 Arbeiten???????
Du kannst arbeiten womit du willst.
Zu deiner "Frage": Man sieht schon an der Überschrift, dass dir einige Begriffe und wahrscheinlich noch mehr ziemlich unklar sind. Ein Browser kann gar nicht "XHTML 1.0 Strict" sein, sondern nur eine Webseite. Sobald du <embed> benutzt, ist die Seite kein valides (X)HTML mehr, völlig egal, mit welchem Browser darauf zugegriffen wird. Der Firefox kann doch nichts dafür, wenn du ein ungültiges Element in den Code deiner Webseite einbindest. Die Aussage "Also Warum nehmen die Coder vom FF das sch... <embed> nicht raus und begnügen sich mit dem <object>" ist totaler Unsinn. Warum sollten die "Coder" eines Browsers etwas aus deiner Webseite "rausnehmen"?!
Davon abgesehen: W3C-Standards heißen deshalb so, weil sie vom Worldwide Web Consortium formuliert werden. Was "Macromedia offiziell empfiehlt", ist da vollkommen irrelevant. Wenn du dich abgeregt hast, schau dir ruhig den Link von DasIch mal an. Die dort beschriebene Methode ohne <embed> wird von allen modernen Browsern korrekt interpretiert, auch wenn sie sich nicht als "robust erwiesen hat" - was immer du damit meinst, ich bezweifle ernsthaft, dass du das selbst weißt.
Das ist eine Neue Suchmaschinenoptimierung des .de.vu-Netzwerkes, die aber den Nachteil hat, dass sie bei transparentem Body durchschimmert. Wenn du in der Styledefinition von body (Zeile 13) aber background-color:white; ergänzt, sollte diese Schrift verschwunden sein.
--
Bei der Gegenehit ein kleiner Tipp, der nichts mit dem Thema zu tun hat: Anstatt
body { margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; }kannst du einfach
body { margin:0; border:0; padding:0; }schreiben. Alle Browser sollten das korrekt interpretieren.
Alternativ kannst du diese Meldung global mit Annoyance Remover abschalten.
Grundsätzlich ist es möglich, per JavaScript auf das Vorhandensein bestmmter Erweiterungen (ich vermute, du meinst Erweiterungen und nicht Plugins) zu überprüfen, auch wenn es, vor allem hier, nicht gern gesehen ist und ich deshalb keine Codebeispiele verlinke.
Dein Ansatz ist jedoch falsch. TamperData oder UrlParams sind nur zwei Möglichkeiten, die beweisen, dass man die Kommunikation mit dem Webserver ganz beliebig sichtbar machen und vor allem beeinflussen kann. Wenn du weißt, dass ich diese beiden Erweiterungen nutze (was übrigens tatsächlich der Fall ist), könntest du mich aussperren. Damit hinderst du mich nicht daran, auf beliebige andere Weise POST-Variablen nach Belieben an deine Skripte zu senden.
Du wirst weder alle Erweiterungen und externe Programme aussperren können, die diese Möglichkeiten bieten, noch kannst du verhindern, dass ich ganz ohne Browser direkt per HTTP mit deinem Server kommuniziere. Schließlich kann jeder UserAgent, der das HTT-Protokoll versteht, mit einem Webserver kommunizieren, dies ist nicht nur den vier großen Browseranbietern vorbehalten. Die Lösung ist also keinesfalls, das Ändern von Variablen zu unterbinden (das schaffst du nicht!), sondern dafür zu sorgen, dass eventuelle Änderungen kein (Sicherheits-)Problem darstellen.
Leute mit bestimmten Erweiterungen auszusperren ist sowieso keine Lösung. Woher willst du wissen, ob die betreffenden Anwender damit auf deiner Seite irgendwas Unerwünschtes anstellen wollen? Dieser Ansatz ist ähnlich kundenfeindlich wie die Kopierschutztechnologien einiger Spiele, die nur aufgrund des bloßen Vorhandenseins von Emulationssoftware den Dienst verweigern. Sowas solltest du vermeiden, es bringt dir mehr Unmut ein, als dass es nützt.