Beiträge von pcinfarkt

Für Bremsen im OS sind meinst die einschlägigen Verdächtigen zuständig.
Schließe Fx als Ursache aus, indem du deine Beobachtung mit einem Test im cleanen Profilzustand bestätigst!

Janis Joplin --- Get It While You Can

sponsored by:
Greatest Hits

[Blockierte Grafik: http://i.imagebanana.com/img/76mdthe6/_dance.gif]

adi1141,
sehe es mir nach. :wink:

Aber wenn ich lese, dass jemand keine Bilder angezeigt bekommt, fallen mir aus jahrelanger Supporterfahrung zunächst immer die üblichen Verdächtigen in einem OS ein - Firewalls, Contentscanner, Virenwächter mit anmaßenden Contentaufgaben...

Vllt. solltest zu zunächst in dieser Richtung einen konsequenten Ursachenausschluss vornehmen.

PS. Ein reproduzierbarer Link kann Helfern auch nützlich sein.

...und ich habe 0 Lust auf irgend welches Bla-Bla.
Das du dir Links gemerkt /gebookmarked hast, weiß ich...

altepoststrasse,
welchen Umfang verstehst du denn unter der gewünschten Synchronisation? Sicherlich meinst du Browserprofil-Daten? Ja?
Bookmarks u./od. Passwords u./od. Einstellungen oder was primär?

Allgemein sollte eine Synchronisation zwischen den beiden genannten möglich sein...

Wozu nochmal?
Ändern doch nichts an der Aussage.

Zitat von Eidatsug

- Fehler: Beim Anklicken des Lautsprechersymbols für einen ausgewählten Titel verschwindet am rechten Rand die Anzeige unter "Jetzt reinhören" und es erfolgt keine Wiedergabe!

WFM

[Blockierte Grafik: http://s1.directupload.net/images/130214/temp/6erfco9m.png]

MIME-Typ: application/x-mplayer2

Die Bibliothek np-mswmp.dll des dafür benötigte WMP-Plug-In muss dazu registriert sein [1]. In dem von dir genutzten OS wird dieses nach Systemeinbindung (Default) auch problemlos vom Browser registriert. Hat nichts mit *Windows Media Player Plugin für Firefox, Version 3.0.2.629* zu tun.

PS. Es sei denn, du nutzt ein Win 64-Bit- Build. Da ist nichts mit WMP zu tun. :wink:

[1] http://kb.mozillazine.org/Windows_Media_Player ff

Der mit vorletzter Nightly-Auslieferung related Bug 755724 sorgt /sorgte zumindest bei aufgesetzten Profilen hier zu *Missverständnissen* :wink: . Ein AUS-Update für das Win 64-Bit- Build wurde mit Fehlermeldung bei Restart bestraft.

UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:21.0) Gecko/20130214 Firefox/21.0 ID:20130214032850 CSet: aceeea086ccb
Pushlog: http://hg.mozilla.org/mozilla-centra…ge=aceeea086ccb

Beta-Webplayer v11.6.602.170 is out.

[Blockierte Grafik: http://s1.directupload.net/images/130214/mgddies8.jpg]

Möglicherweise gibt es ja User, welche bisher auch folgende Schalterkonfiguration nutzen:

// AllTab - CtrlTab, Default false
user_pref("browser.allTabs.previews", true);
user_pref("browser.ctrlTab.previews", true);

U.U. ist /war diese Schalterstellung auch für Nicht-TMP-User interessant. :wink:

Der heutige Nightly wird nicht mehr über den AllTab-Preview- Schalter verfügen (Bug 670684). D.h., ein Preview-Ansicht aller Tabs (1-ner Gruppe) schaltbar über den AllTab-Button - in der Ansicht von Ctrl-Tab - wird nicht mehr möglich sein [Abb.].

[Blockierte Grafik: http://s1.directupload.net/images/130212/temp/cbfcessz.png]
[Abb.]

CtrlTab- Preview, also

[Blockierte Grafik: http://s14.directupload.net/images/130212/temp/7go6h2rc.png]

bleibt mom. auch funktionell erhalten.
Das Canceln des AllTab-Preview (Ctrl-Tab-Panel) ist kein k.o- Kriterium, aber ich finde es eigentlich schade.

UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:21.0) Gecko/20130211 Firefox/21.0 ID:20130211201028 CSet: 3625224b14e

//
...was nicht den Unterschied zwischen 32-Bit- + 64-Bit- Instanzen (Mozillen) beim TO erklären würde...
(Abgesehen von Clean-Profil-Tests; s.d.a.w.o.)

Zitat von Suker

- Verstehe ich nicht, da ich auf meinem 64-Bit-System zu 90 % 32-Bit-Programme am laufen habe.

...dieser auskommentierte Teil galt dem Vorredner in Deutung deiner Plug-In-Listung .
Du als 64-Bit- User solltest die Gründe kennen.

Zitat von Suker

- Hm, aber wie erklärt sich, dass sie im Internet Explorer (64 UND 32-Bit) keine Probleme macht?

Stimmt.
Dafür habe ich auch (mom.) keine Erklärung.
Jedoch stoße ich bei Recherchen zu ähnlichen Problemen des öfteren auf AMD Radeon!

Mir wäre im Ursachen-Ausschluss schon der reproduzierende Test eines Users in vergleichbaren Umfeld wichtig.

//
Falls der Opera Suite die Plug-In (wie üblich) nicht direct untergeschoben werden, greift diese Suite auf eines vorhandenen Firefox zurück. Und das um so leichter, wenn ein (veralteter) Ordner \plugins zur Verfügung steht.

http://kb.mozillazine.org/Firefox_hangs#…_Firefox_window ff

Das hat 0 mit Google zu tun. Aber immer mit User, welche ggf. nicht genau wissen, was sie im System einbinden und sich anschließend auch nicht mit Struktur + Funktionen dieser SW beschäftigen. Und nur mit Google Earth in den Vorgarten des Nachbarn schauen und anschließend erstaunt fragen, woher man bei Google bekannt ist.

Eine Programmbibliothek kann man blind machen. Auch Ausführungen im System kann man stoppen /unterbinden.

Aber man sollte dieses - wie auch die Programmeinbindung - bewußt tun. Und anschließend nicht fragen, warum bspw. irgend welche Updates (bis hin zum Silent Update von Google Chrome) nicht mehr funktionieren.

//
...zumindest bei keiner Abweichung von einer Default-Einbindung!
Davon unabhängig gilt für die profiles.ini, Win + dem Lieblingskonto immer:

%APPDATA%\Mozilla\Firefox\

.

JeGe,
ich kenne diese Umzugsanleitung nicht! :wink:
Aber für die Default-Einordnung der Browserprofile unter 64-Bit gilt (wie auch bei 32-Bit):

%APPDATA%\Mozilla\Firefox\Profiles\

bezogen auf das Lieblingskonto.

//

Zitat von Bernd.

- Ist dir eigentlich nie aufgefallen, dass [...] die Liste ist auch wesentlich länger. Also - deaktivieren und testen.

...wofür jeder 64-Bit User dieses Browsers (und Waterfox ist letzlich auch nur eine Mozille) sofort eine Erklärung hat /die Erklärung kennt! :lol:

Listenmäßig gesehen...

Suker,
zu VLC + Foxit kann hier keine Aussage getätigt werden.

Also ich komme noch nicht ganz von deiner *AMD Radeon HD 7340* weg. Vllt. könnte dazu ein User mit reproduzierbaren Umfeld etwas sagen.

Nun, ganz so kann man das nicht stehen lassen.
Also noch etwas *Erhellendes* oder auch zusätzlich *Verwirrendes*. :wink:

Jeder Schnipsel mit einem funktionierenden Chrome-URL wird auch umgesetzt, wenn man diesen Chrome-URL nutzt.
Wenn man also bspw. die Zeile

@-moz-document url-prefix(chrome://mozapps/content/extensions/extensions.xul)

einsetzt, dann muss man das Tableau auch so in seiner Browseroberfläche aufrufen; bspw. als Bookmark. Nutzt man aber ständig den Menüeintrag unter Tools, dann werden Schnipsel mit dieser Zeile nicht funktionieren. Dann nur so:

@-moz-document url-prefix(about:addons)

.

Will sagen, dass es beim Tableau des Add-Ons-Manager (fast nur hier!) eine Diskrepanz zum *gültigen" Chrome-URL [1] gibt. Wenn man bspw. profil die Extension GM nutzt, kann man diese Diskrepanz augenscheinlich mit Aufruf des Chrome-URL im Vergleich zum Menü-Aufruf ganz simpel reproduzieren (Categorie-Anzeige).

MK204,
sehe es mir nach. Deine im Thread aufgeworfene Frage verstehe ich nicht. Ich glaube mich zu erinnern, dass dir irgend wann mal der DOMI erklärt wurde. Bei dessen Nutzung bekommst immer den gewünschten URL in der Adresszeile des DOMI angezeigt! Wenn du also das Tableau Add-Ons-Manager über das Menü aufrufst und den DOMI darüber stellst, wird in der der Adresszeile (des DOMI) *about:addons* als Chrome-URL stehen. Übrigen kannst im Edit-Menü auch ablesen, dass es sich dabei um ein Chrome-Elerment handelt - also kein Content (deine @namespace-url im Beitrag #9 ist falsch, aber Stylish schluckt sowas!). Der Rest sollte mit *Inspect* + *Find a node* kein Problem sein!

[1] http://tinyurl.com/b483n

ulifix,
Eine System-Meldung?

http://kb.mozillazine.org/File_types_and_download_actions ff