Beiträge von pcinfarkt

Der heute noch anstehende Build-Respin wird den related Bug 307181 - Eliminate wait while restarting Firefox after update (apply update in background) - enthalten [1]. Und man hat gleich noch die extensionunabhängige Freigabe des
PDF-Inline- Feature [2] eingebaut (Bug 740795 - Don't ship PDF Viewer as an add-on). Was bspw. ohne weitere Aktionen im 64Bit- Build werkelt...

Changeset: http://hg.mozilla.org/mozilla-central/rev/c20d415ef1b5
UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120522080220

[1] https://wiki.mozilla.org/Background_Updates
[2] https://www.camp-firefox.de/forum/viewtopi…3a65e9e#p758322

[Blockierte Grafik: http://www.img-teufel.de/uploads/ziehd56510d0gif.gif]

Für Firefox - [1], [2].

[1] http://kb.mozillazine.org/Error_loading_any_website ff
[2] http://kb.mozillazine.org/Error_loading_secure_sites ff

bkoray,
vllt. kannst du etwas deutlicher werden.

Nach meiner Kenntnis gab es von v12 auf v13 keine marginalen Änderungen [1] bezüglich des Handlings der Download-History, des DL- Managers (Tableau-Anzeige) der Mozille ¹). Die Download-History ist nach wie vor bei dem optionalen Vorhalten einer History auch ein *History-* Bestandteil. Ein Löschen dieser History kann optional + damit augenscheinlich für den DL-Manager vorgenommen werden. Der entsprechende Bestandteil History in den Places bleibt davon unberührt.

¹) Prophet :
Ab der v14 gibt es einen geänderten Schalter für die augenscheinlich *Gestaltung* (also Halten, Löschen, wann Löschen) des DL- Panels- Inhaltes mit 3 möglichen Stellungen. Aber auch in dieser Version bleibt die DL-History Bestandteil der (Gesamt-) History!

[1] https://wiki.mozilla.org/Features/Relea…king#Firefox_13

Zitat von Bernd.

- Nur lesen hier auch Endkunden mit, weil kein abgeschlossener Bereich.

...wie überall :wink: .
User sind selbstständig denkende Wesen, welche nicht dauernd unterschätzt werden sollten...

Zitat von Bernd.

- Vielleicht wäre ein Warnhinweis auf den Status hilfreich, denn was zB Flash 11.3 angeht gibt es sowohl auf 32 als auch 64bit massive Probleme bis hin zum Absturz von Firefox.

...wie überall :wink: .
Wobei man solche Aussagen an diesem Brett nicht separat sehen kann /sollte.

Zitat von Bernd.

- Eigentlich hängt 11.3 immer ein wenig hinterher, was Fixen der Sicherheitslücken angeht, davon konnte ich hier bislang nichts lesen.

...wie überall :wink: .
Jedoch wäre ich bei einer solchen allgemeinen Aussage an aussagekräftigen + glaubhaften Quellen interessiert. Und zwar für alle der *scheinbar* vielen Fälle. Mir ist zumindest 1-ner bekannt [1]. Wobei der Fix auch in der Beta innerhalb von Stunden erfolgte!

PS. Eigentlich wollte ich mich zu den letzten Beiträgen des etwas ungeschickten aber gut gemeinten Threads gar nicht äußern! :cry:

[1] https://www.camp-firefox.de/forum/viewtopi…5aa179e#p795257

uwius,
hast du einen zugänglichen Link zum Reproduzieren deiner Aussage?

https://bugzilla.mozilla.org/show_bug.cgi?id=714281

PS. Mit wenigen css- Zeilen kannst du dir die dauerhafte Anzeige des AllTabs- Button unabhängig vom Tab Overflow zurückholen. Falls gewünscht...

:wink:

S.a. Antwort #2 + [1]!
[1] http://forums.mozillazine.org/viewtopic.php?p=11999213#p11999213 ggf. ff

Hier kann der Report Bug 756796 - crash in TypeConstraintPropagateThis::newType - der heutigen Ausgabe des m-c- Builds (localisierte Ausgabe) bestätigt werden.

UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120519030527

Wishbone Ash –-- Warrior

sponsored by:
Argus (Track 06)

[Blockierte Grafik: http://www.img-teufel.de/uploads/dance1fbf0ce4gif.gif]

//
rainer.wendland,
ich glaube nicht, dass du diese Wunschvorstellung mit einer Extension oder einem Script realisieren kannst.

Du müsstest wahrscheinlich in die Extension eingreifen um den Hardcode von *Open in a new tab* in ein *Window* - besser ein Popup-Window mit Resizer zu wandeln. Und falls du das schaffst, dann wird diese Änderung beim nächsten Update wahrscheinlich überschrieben.

Am ehesten sollte dein Wunsch eine Realisierung-Chance haben, wenn du dich mit Autor in Verbindung setzt und deinen Wunsch plausibel darstellst + begründest!

Beachte!
Simple Mail ist nicht mit M1 vergleichbar und kein vollwertiger Mailclient.
Die Mozille wurde seinerzeit ausgehend von der Mozilla-Suite getrennt in Browser (Fx) + Mailclient (Tb). Deswegen wird eine Extension auch nie den gesamten Komfort zurückholen können + wollen!

Zitat von CoreKracker

- OK, bei dieser Seite war mein Problem:
http://www.aaregusler.ch/index.php?id=163

...oder ist noch?
Falls ja, überprüfe deine registrierten Plug-In! Keine Probleme gibt es mit der aktuellen Rapid-Final + der registierten Bibliothek von bspw. dem Adobe Reader!

Noch nicht gelöst ist das Problem der Darstellung einer eingebetteten PDF mit dem künftigen Feature *Show PDF inline*. Da wird bei Mozilla noch gewerkelt [1]. Keine Probleme gibt es mit anderen alternativen Browserentwicklungen. Da werden auch eingebettete PDF's *inline* dargestellt!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=738967

AMG,
Vorbehalt: Nutzung der Extension!
Aber so viel ich weiß tritt das Verhalten seit dem Build-Respin 20120510 auf (comment #22) [1]. Google-NG - [2]. Eine Dev.Version beim Autor wurde von mir nicht gefunden [3].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=589032#c22
[2] http://groups.google.com/group/forecastfox-users/ ffd
[3] http://www.getforecastfox.com/

Die Entwicklung der Rapid-Releases geht auch mit Anpassungen des UA einher [1]. Im http://1.HJ/2012 erfolgte zumindest bei der Alpha 1 der Mozille erneut eine Präzisierung. Das bisher ausgewiesene Gecko-Datum

Final ¹): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 ID:20120420145725
Beta ¹): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0 ID:20120509070325
Alpha 2: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120516 Firefox/14.0a2 ID:20120516042006

wurde durch die Gecko-*Version* ersetzt [2].

Alpha 1: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120516030515

¹) Final + Beta mit bekanntem Freeze UA Build-ID (Bug 591537)

[1] https://www.camp-firefox.de/forum/viewtopi…9046978#p702398
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=588909

Irishsetter,
wie genau gehst du ins INet (Zugang)?

seilfrei,
bei einem syntaktisch richtigen Aufruf des PM und einer offenen Rapid-Release-Instanz öffnet sich in einem nicht manipulierten OS immer ein neues Window der bereits offenen Instanz!

...ist mir letztens bei diversen Tests aufgefallen. :wink:

Der Schalter (optionale Einstellung bzgl. des Erlaubens der seiteneigenen Farben)

browser.display.use_document_colors

hat per Default den Boolean-Wert *true*. Wenn dieser in der aktuellen Alpha 1(v15), 2(v14) und in der Beta (v13) auf *false* gekippt wird, verschwinden die Thumbnails von der NewTabPage. Es bleiben nur die Rahmen mit den Bezeichnungen der gewählten Seiten über. Einen Zusammenhang zw. Thumbnails + Webseitenfarben sehe ich eigentlich nicht zwingend ...

Wenn man das Feature in der aktuellen Final der Rapid-Releases (v12) aktiviert - also nur die Implementation des Features testet - bleiben die Thumbnails bei Wertveränderung des obigen Schalters erhalten. Ich denke, dass sich da etwas durch Rückschreibung in das Profil und der Handhabung der Bildchen (als Hintergrund) eingeschlichen hat.

UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120516030515

=================
Edit --- das fiel auch anderen auf
Bug 737877 - [New Tab Page] thumbnails disappear with browser.display.use_document_colors=false

Zitat von seipe

- Wenn ich seit ein paar Tagen Nightly aktualisiere [...] dann jedesmal die komplette Datei heruntergeladen. Kann das jemand von Euch bestätigen?

WFM
Hier keine Probleme mit dem inkrementelle Update. Für das Einspielen eines Komplett-Updates gibt es zumindest auch bekannte Gründe.

Zitat von seipe

- Konnte jetzt beobachten, dass sich bei geschlossenem Nightly im Profilordner >parent lock< nicht löscht. Hängt es eventuell damit zusammen?

Nein.
Einen Zusammenhang zwischen der permanenten parent.lock (ab v13) und dem Einspiel eines Komplett-MAR sollte es nicht geben.
Die *Schlachtung* einer weiteren *heiligen* Mozilla-Kuh hat andere Gründe. Meine Worte. Es geht dabei im weitesten Sinne um das Exit /Restart- Verhalten, vor allem dem (der Erfassung) des Start-Crash und tangiert auch das Safe Mode- Verhalten (Start).

Zitat von vantaris

- demnach dürfte ja keiner mehr die Seite aufrufen können,oder?

... das war nicht deine ursprüngliche Frage! :wink:

Und nein.
Das ist ein Sicherheitshinweis (Phishing Protection, Safe Browsing), in dem von dir optional so eingestellten /von dir übernommenen Voreinstellungen deines Browserprofils. Bei Belassen dieser Einstellungen und nach Lesen von angebotenen Zusatzinfos kannst du diese Warnung *ignorieren*. Möchtest solche Warnungen nicht mehr sehen, kannst du Safe Browsing /Malware-Schutz optional abschalten [1].

Zitat von vantaris

- Kann man diese Seite manuell aus dieser Blacklist löschen, [...]....."

Jein.
Falls du dir sicher bist, kannst du die Löschung bei Google für die Mozille von der Blacklist beantragen [2].

[1] http://kb.mozillazine.org/Browser.safebrowsing.enabled ff
[2] http://www.mozilla.org/en-US/firefox/phishing-protection/ ff

wosaha,

[Blockierte Grafik: http://www.img-teufel.de/uploads/WS277a4eaaf25png.png]

http://kb.mozillazine.org/JavaScript#Adv…Script_settings

Ich kann deine Beobachtung bestätigen.

Andere Browser.
Der Mozilla-Browser arbeitet anderes als manche andere Browser mit ein einer profil angelegten und sich aktualisierenden Blacklist!