Vermutlich am Quelltext, den wir uns ja wegen fehlendem Link zur Seite nicht ansehen können.
Beiträge von bugcatcher
-
-
Gut zu wissen. Muss ich mir merken.
-
Und nochmal... die Richter können nichts für die Gesetzgebung.
-
immerhin. : )
-
Zitat
Could not find email template file :: report_notify
DEBUG MODE
Line : 111
File : emailer.php
kaputt....... -
z-index funktioniert nur in kombination mit position-angaben.
deinem #content fehlt noch:
wenn es kein layer ist, kann es auch nicht irgendwo in der höhe verschoben werden. ; )
ohne die angabe hat #content die selbe höhe wie der body. und der ist halt unter dem #headerbg (z-index:2). : )
-
warum probierst du es nicht einfach aus? : )
-
Tipp... der Body selber hat z-index:0; .... wenn du irgendeinen layer auf -1 setzt, liegt dieser layer HINTER/UNTER dem body.
IE ist zu doof, der kann sowas mit -1 nicht.
-
M1 build bringen bei mir keinerlei höhere Werte als die normalen Builds. Bei M2/M3-Dingern mag das anders sein.
-
Nunja. Selbst wenn in 6 Monaten noch nix neues rauskommt. IE (z.B.) ist seit über 3 Jahren nicht weiterentwickelt worden (und die aktuellen Ankündigungen sind nur Rumbellerrei. Als wenn die von jetzt auf gleich einen Neuen browser präsentieren könnten.... Siehe Longhorn.... kommt! Bestimmt! irgendwann...). Hotfixes für sicherheitslücken werden auch weiterhin von irgendwem schon zur verfügung gestellt werden. Schliesslich kann jeder Patches anbieten und bei Mozilla.org abgeben. Zumal die meisten sicherheitslücken Produktübergreifent sind, sprich... es würde die Mozilla-Suite, Firefox, Thunderbird und co gemeinsam betreffen. Und da Mozilla.org nicht nur am Firefox arbeitet, sind genug leute da, um dort zu Fixen. Aber da Mozilla.org soviele Projekte laufen haben, sind die pro Projekt was unterbesetzt..... das führt halt nur zu einer verlangsamung.
-
Klar. Ich bin auch strategisch vorbereitet.
Dauerndes reloaden der "Beiträge seit dem letzten Besuch anzeigen"-Seite und sobald was neues erscheint, aufrufen direkt antworten und den inhalt anschliessent passent editieren, weil man die frühe postingzeit ja schon eingesackt hat. ; )
-
http://www.heise.de/newsticker/meldung/57305
Die Richter können nichts für die völlig überholte Rechtslage.
-
Am Ende ist der nicht. Die Entwicklung wird sich höchstens verlangsamen.
-
Ich bin Road-Runners Meinung. Das lohnt nicht zu "Reparieren". Ich glaub das einzigste was noch schlimmer ist als Publisher ist HTML-Export aus Word. Sogar Frontpage ist besser. Und das ist schon übel.
-
Ist nicht unbedingt "schwachsinn". Je mehr Verbindungen ein System verwalten muss, um so "instabiler/gefährdeter" wird es. Für leute mit schwachen rechnern und kleinen Leistungen macht sowas sehr wohl Sinn. Und da Firefox quasi "sicher" ausgeliefert wird (ohne gross features/einstellungen aktiviert, die unter umständen probleme bereiten könnten), sind standardgemäss viele optionen gedrosselt oder deaktiviert. Firefox wird also quasi mit angezogener handbremse ausgeliefert, damit sich keiner "zu tote" surft. Wer meint, er müsse den Firefox aufbohren und den turbulader zuschalten, kann das gerne machen. aber auf eigene verantwortung. : )
-
-
Nun... am einfachsten lässt sich das wohl beschreiben wie folgt:
Prefs.js
schreib/leserechte; primärdatei; vom firefox erstellt
hier speichert Firefox alle Einstellungen und ÄnderungenUser.js
nur lese-datei/schreibgeschützt; übergeordnet; vom benutzer erstellt
die hier eingetragenen werte überschreiben bei jedem browserstart die entsprechenden werte in der prefs.js.wenn ich Firefox starte und was ändere, dann wird das in der prefs.js gespeichert. starte ich das nächste mal firefox, dann werden diese änderungen aufgerufen. vor dem start werden die werte der prefs.js durch die der user.js überschrieben, womit änderungen verloren gehen und durch die festen angaben in der user.js ersetzt werden.
zfkum: die prefs.js wird indirekt von der user.js überschrieben. Firefox läd die Variablen beim Start in den Speicher... zuerst die der prefs.js und dann die der user.js (und überschreibt dann die Einträge der prefs.js im speicher). beendet man den Firefox, speichert firefox die einstellungen in die prefs.js ... wenn diese wärend des betriebs (oder halt beim start durch die user.js) geändert wurden, landen die einstellungen dann in datei-form in der prefs.js ...
-
bc: benutzt Du eine andere Build? Bei mir geht das nämlich auch nicht, standard fx1.0.1de ... Und ich dachte das Problem würde erst mit 1.1 behoben werden, wenn ich das richtig weiss.
Moox seine Builds könnten den Patch schon drin haben.... weiss das aber nicht genau....
-
wirst zumindest keine lösung finden.
-
Ohne Link kann man dazu nix sagen.