1. Nachrichten
  2. Forum
    1. Unerledigte Themen
    2. Forenregeln
  3. Spenden
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. camp-firefox.de
  2. bugcatcher

Beiträge von bugcatcher

  • JavaScript anwendung wird von Firefox geblockt.

    • bugcatcher
    • 23. März 2005 um 16:40
    Zitat von Les Royaux

    KEIN POPUP.

    Zitat von bugcatcher

    aber solange der popupblocker aktive ist, wird keine seite geöffnen.


    Lesen, verstehen, dann motzen.

    Zitat von Les Royaux

    das zitat verstehe ich nicht, wen oder was schließe ich mit der funktion aus?? Es soll doch nur ein ladebildschirm kommen und dann die seite automatisch in einem popup öffnen lassen. Was hat das mit ausschließen zu tun???


    Mach mal Javascript aus. Vorlesebrowser (für Blinde) oder einfache Textbrowser, aber auch Handys, PDAs usw. können in der Regel kein Javascript. Die Bekommen absolut nichts zu sehen, weil die an deinem überflüssigen "Ladebildschirm" hängen bleiben. Nichtmal ein <noscript>-Bereich mit einem Link zu Deiner Seite ist vorhanden. Nichts. Und darum sperrst Du Leute aus.

  • Quälen an der Quelle

    • bugcatcher
    • 22. März 2005 um 21:48

    Erster artikel hier:
    http://www.spiegel.de/netzwelt/techn…,347074,00.html

    Steinigt mich. Ich find den Artikel Stellenweise gut. Das ganze mit dem "Sobald mehr Marktanteile -> Viren" ist zwar wieder der Standardmüll, zugegeben. Aber zumindest Mich überfordert Linux (und dabei ist es egal ob SuSE, oder Co) dauernt. Für Windows muss ich Virenscanner installieren (nagut, nicht wirklich)... aber immerhin bekomme ich das problemlos hin. Linux ist bei mir da immer 1 Schritt vor, 2 Zurück (SuSE installieren, rumfummeln, versuchen was zu installieren, nix geht mehr, SuSE neu installieren... software nochmal neu... irgendwie hinbekommen... was anders installieren. linux tot..... neuinstallieren... usw.). Die Softwarepakete sagen mir auch nie irgendwas, heissen immer irgendwie kryptisch irgendwie. Linux fordert schon von Beginn an sehr viel mehr von einem User ab als Windows oder Mac. Ob man das nun wahrhaben will oder nicht.

  • IE macht einen Margin wo keiner sein soll

    • bugcatcher
    • 22. März 2005 um 21:30

    Mach ein <br> hinter das <img>, weil sonst gibts ein ungewolltes leerzeichen, was zu einer textzeile führt in der das bild an der baseline vom text ausgerichtet wird.

  • "padding" lässt FIREFOX layer falsch positionieren

    • bugcatcher
    • 22. März 2005 um 17:44

    auch interessant:
    http://webfx.eae.net/dhtml/boxsizing/boxsizing.html
    http://www.fabrice-pascal.de/artikel/ie5boxmodel/
    http://www.howtocreate.co.uk/wrongWithIE/
    http://barrierefrei.e-workers.de/workshops/ie-fun/index.html

  • Microsoft VM

    • bugcatcher
    • 22. März 2005 um 13:04

    Sicherlich wieder das Problem, dass Quicktime sich für Flashfilme verantwortlich fühlt...

  • "padding" lässt FIREFOX layer falsch positionieren

    • bugcatcher
    • 22. März 2005 um 11:56

    Ich trickse IE genre mit max-height/max-width aus.

    Code
    #lalala{
     width:100px;
     max-width:80px;
     height:100px;
     max-height:80px;
     padding:5px;
     border:5px black solid;
    }


    Allerdings muss man aufpassen.

    Erstens... wenn ein neue version von IE plötzlich max/min-width/height lernt, ohne das Boxmodel zu korrigieren, kommt Müll bei rum.

    Zweitens... Opera hat nach 7.0 irgendwie max-height verlernt und macht nurnoch max-width richtig. Sehr seltsam und vor allem doof. Der Trick geht also nurnoch mit max-width.

    Drittens... wenn man den richtigen Doctype nimmt, kann IE das richtige Boxmodel (z.B. in XHTML 1.0 Strict).

    Ob man jetzt mehrfachangaben macht (sich überschreibende Klassen, ob per IE-Spezial-Code "if IE", oder über unkorrekte Addressierungen, oder halt per browserweiche andere css-dateien) oder direkt xhtml benutzt ist immer etwas Glaubensfrage.

    In der Regel umgehe ich solche probleme in dem ich die kombination von height/width zusammen mit padding/border vermeide. lieber einen zusätzlichen container. da bin zumindest ich auf der sicheren seite.

    Code
    <div style="width:100px; height:100px;">
     <div style="border:5px black solid; padding:5px;">
      5px border, 5px padding, 80px inhalt
     </div>
    </div>
  • CSS anstatt TransparentPixel

    • bugcatcher
    • 22. März 2005 um 00:08
    HTML
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
     <head>
      <title>Unsichtbarer Abstand</title>
      <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
     </head>
     <body>
      <p>Blah, lalala dings, <span style="padding-left:50px;"> blah, usw.</p>
     </body>
    </html>


    ?

  • Firefox und Thunderbird mit EINEM Profil von Mozilla

    • bugcatcher
    • 21. März 2005 um 21:40

    Ich meine, du solltest besser nicht ein Mozilla-Profil für Firefox benutzen. Die sind sich zwar sehr ähnlich... aber es kann da sehr schnell zu komplikationen kommen. Auch wenn es jetzt problemlos geht... ich würde davon Abstand halten.

  • JavaScript anwendung wird von Firefox geblockt.

    • bugcatcher
    • 21. März 2005 um 21:17

    Hier: http://abi07.der-kobold.net/index.php hat sich nix geändert. Falsch abgespeichert?

    Und hier: http://www.bugcatcher.de/files/kobold.html ist der Beweis das es geht. Danke, dass ich mir die Mühe hab machen müssen.

    Abschliessent: so ein Blödsinn gehört eh verboten. Leute per Skript aussperren, obwohl das was das Script bewirkt völlig überflüssig ist. Insofern weiss ich nicht wo man ein anderes ähnliches Script findet. Javascript darf für die Funktionalität einer Seite einfach nicht erforderlich sein.

  • JavaScript anwendung wird von Firefox geblockt.

    • bugcatcher
    • 21. März 2005 um 18:29
    Code
    if (!document.all) location.replace(locationAfterPreload)


    in

    Code
    if(!document.getElementById){location.replace(locationAfterPreload);}

    und

    Code
    eval("document.all.cell" + (h+1) + ".style.backgroundColor = hilite[h]");


    in

    Code
    eval("document.getElementById('cell" + (h+1) + "').style.backgroundColor = hilite[h]");

    ändern. dann sollte es gehen.

    aber solange der popupblocker aktive ist, wird keine seite geöffnen. und browser die kein getElementById können, landen auf einer leeren seite. browser die keine javascript können (oder aktiviert haben) bekommen auch nur eine leere seite zu sehen. wenn Javascript, dann bitte darauf achten, dass es auch ohne geht. stichtwort: "barrierefrei"

  • Java/Javascript

    • bugcatcher
    • 21. März 2005 um 12:48

    Testhalber. Rein testhalber. Und da es nicht auf FX1.0 läuft, hab ichs angepasst... und gleich noch aus Übungszwecken übersetzt. Ich benutze es auch nicht aktive. Für Shimoda-Krempel hab ich ein Testprofil (wobei ich bisher im quelltext nix schlimmes hab finden können). Ich finde so'n Ding an sich aber sehr gut (ähnlich wie bei Netscape8... das einzig gute Feature von N8). Wünschte mir nur es könnte auch plugins kontrollieren. Da Shimoda das Ding aber wohl eingestellt hat, geh ich mal nicht davon aus, dass da noch viel kommt.

  • Java/Javascript

    • bugcatcher
    • 21. März 2005 um 12:17

    Der Policy Manager (z.D. "Richtlinienmanager") geht aber nur Javascript-Dinge an. Es werden keinerlei Java oder andere Plugin-Dinge damit behandelt.

  • Java/Javascript

    • bugcatcher
    • 21. März 2005 um 11:07

    Meine Übersetzung aber: http://www.bugcatcher.de/files/policy_m….2004081801.xpi

    Ich gab aber keinerlei Garantien.

  • Keine Farben, kein Javascript mit dem Firefox

    • bugcatcher
    • 21. März 2005 um 11:03
    Zitat von raptorrs

    1) Auf der Seite sind zwei horizontale blaue Linien. Die sind im Firefox einfach nicht darstellbar. Keine Farbe!!


    color wird für Vordergrund-Farbangaben benutzt. Für <hr> musst du background-color benutzen. Übrigens zeit IE die <hr>'s zu kurz an.

    Zitat von raptorrs

    2) Obwohl direkt positioniert, ist die Lage des zentralen Bildes anders als beim IE.


    Naja. Bei sovielen Schreibfehler wundert mich eh nicht viel:

    Code
    <div align="left"font size="-2"style="position:absolute;top:230px">


    Räum mal ein wenig auf, dann schauen wir uns das nochmal an.

    Zitat von raptorrs

    3) der Firefox scheint andere Farben anzuzeigen, als der IE


    http://www.bugcatcher.de/files/colorbugie.html

    Zitat von raptorrs

    4) ich habe ein kleines Javascript in die Seite kopiert (die legendäre rechte Maustaste!) um zu sehen, ob Javascript funktioniert. Bei IE geht das auch, der Firefox ist völlig unbeeindruckt.


    IE ist auch doof und gibt Webseiten zugriff auf das Browserinterface. So einen Mist gibt es bei Mozilla nicht. Gut so!

    Zitat von raptorrs

    5) Die background-color soll durch CSS gesteuert werden auch dies funktioniert beim Firefox absolut nicht.


    Du verwendet auf der ganzen Seite auch kein mal diesen Befehl.

    Ansonsten:

    Code
    <style type="text/css">
    <!--


    ...und...

    Code
    //-->
    </style>


    ... haben NICHTS in einer ausgelagerten CSS-Datei zu suchen.

    Vielleicht doch besser weg anheuernt, der weiss was er macht. Bei Privatseiten macht das ja nicht... aber bei Firmenseiten? Da droht am Schluss noch Image-Schaden.

  • HTML/CSS: Stylingproblem mit Rowspan

    • bugcatcher
    • 17. März 2005 um 23:05

    wenn du den wert nicht hast... einfach erstellen (integer). wert sind halt millisekunden. ich hab 100 eingestellt.

    rv:1.8b2 Gecko/20050317 ist sehr aktuell. (20050317 = erstellt am 17.05.2005) sowas hab ich befürchtet, dass das problem nicht 100%ig gefixt ist. dafür ist das problem zu... hem... "seltsam".

    über umwege kann ich erst was sagen, wenn ich dein problem mal in "action" gesehen hab.ist gut möglich dem problem aus dem weg zu gehen.

  • firefox-mozilla-thunderbird, bin ich hier richtig?

    • bugcatcher
    • 17. März 2005 um 20:50

    Das einfachste wird sein, du startest windows neu, damit die zugriffsperre aufgehoben wird. nach dem neustart solltest du die dateien löschen können.

  • HTML/CSS: Stylingproblem mit Rowspan

    • bugcatcher
    • 17. März 2005 um 20:36

    Bei Rowspans hab ich es so eigendlich auch noch nicht erlebt/von gehört. Der "Slashdot"-Bug hat seinen Namen von der gleichnamigen Seite. Gelegentlich kann es dort passieren, dass bei einem noch nicht ganz geladenen Table ein (Menu)TD erstmal volle Seitenbreite erhält, bis das andere (Inhalts)TD geladen wird. Das Menu innerhalb des ersten (Menu)TDs ist ebenfalls auf 100%-Breite ausgelegt und nimmt diesen platz auch erstmal bis zum nachladen des zweiten (Inhalt)TDs, gibt dann aber aus irgendeinem grund wegen des darin enthaltenen 100% Tables den platz nichtmehr frei, so dass das zweite (inhalts)TD rechts neben das erste 100%(Menu)-TD geheftet wird und die ganze seite ~150% (also mehr als 100%) breite einnimmt, obwohl eigendlich das erste (menu)TD sich anpassen sollte.

    Gibt dies in verschieden varianten, aber immer die selben syntome.

    Firefox 1.1 wird sich wohl noch bis juni/juli hinziehen, da noch über 100 Bugs vor dem Release behoben werden sollen. aber das ist auch nur eine vorsichtige angabe. kann auch länger dauern.

    Wenn du mutig bist, kannst du mal eine aktuelle Nightly versuchen. Die müsste den bugfix bereits enthalten. ist aber nur erfahrene user geeignet, da erweiterungen mit unter "auslaufen", also als veraltet markiert und deaktiviert werden können und damit ausfallen. gleiches gilt auch für themes. man weiss also nicht, wass passiert. auch kann es sein, dass eine nigtly einen neuen bug hat... mit unter auch mal schwerere (was aber sehr selten vorkommt, aber nicht auszuschliessen ist). ist halt eine zwischenversion direkt vom entwicklertisch.

    über about:config kann man den interval tatsächlich ändern. der wert nglayout.initialpaint.delay ist dafür zuständig. die zahl sind millisekunden. kannst ja mal was mit spielen. allerdings bezeifle ich dass das viel hilft.

  • HTML/CSS: Stylingproblem mit Rowspan

    • bugcatcher
    • 17. März 2005 um 18:51

    Ohne Testmöglichkeit werde ich mich nicht zuweit aus dem Fenster lehnen. Aber wenn es zuweilen unterschiedliche Darstellungen gibt, ist das wohl der "Slashdot"-Bug (oder was verwandtes). Das liegt daran, dass Firefox bereits anfängt seiten zu rendern, wenn noch nicht alle Daten bereit steht... allerdings versucht Gecko (so heisst die LayoutEngine von Mozilla) "Energie" zu sparen, so das nicht bei jeder Darstellungsaktuallisierung wärend des Ladevorgangs die ganze Seite neu gerendert wird, sondern nur die Teile, die sich ändern. Sowas kann in gewissen fällen, je nachdem wie der interval der Darstellungskorrektur und der Ladezustand der Seite liegt, zu unterschiedlichen Darstellungen führen. Das Features ist an sich gut, hat aber kleine Macken. Der Slashdot-Bug soll offiziell bereits behoben sein und in Fx1.1 einfliessen. Ob der aber auch das Problem behebt? Keine Ahnung. Wird man sehen.

  • zweite Schnellstartleiste möglich?

    • bugcatcher
    • 17. März 2005 um 18:43

    "Schnellstartleiste" .... *kopfschüttel*

    Nenn das Kind doch bitte beim richtigen namen.... Das nennst sich "Lesezeichen-Symbolleiste" .....

  • Probleme mit Layer und Z-Index

    • bugcatcher
    • 17. März 2005 um 15:39

    Vorschlag zur Güte: Ich würde den Layer2 (bzw. das iframe) einfach was weiter nach rechts schieben (50px?) und um den wert verenge. da du auf 1024 optimiert hast (zwangsweise bei absoluten werten) fällt das nicht weiter ins gewicht und gecko-user können dennoch relative leicht navigieren, da die schaltflächen noch gut anklickbar sind..... die drei pixel die man zur zeit an platz hat, macht das navigieren für normaluser unmöglich. das wird du wohl nicht wollen, oder?

Unterstütze uns!

Jährlich (2026)

21,3 %

21,3% (138,31 von 650 EUR)

Jetzt spenden
  1. Kontakt
  2. Datenschutz
  3. Impressum
Community-Software: WoltLab Suite™
Mastodon