dlarah: Evtl. kurz mal web.whatsapp.com in die Ausnahmen für den Verbesserten Schutz vor Aktivitätenverfolgung (siehe letzter Screenshot) aufnehmen und erneut ausprobieren...?!
Beiträge von patrick.weiden
-
-
Wie im Screenshot dargestellt, sieht es bei mir aus. Es wird gar kein "Cookies und Website-Daten löschen..." angezeigt.
Und zum Verbinden mit dem Smartphone kommt es auch nicht ... somit kann ichg auch nichts trennen ...
dlarah: Dieses Bild erscheint bei mir, sobald ich web.whatsapp.com aufrufe und dabei alle Cookies blockiert werden (mache ich z.B. via Cookie AutoDelete Add-On). Sobald ich über das Add-On die Cookies für web.whatsapp.com erlaube, wird die Seite geladen, die bei 2002Andreas zu sehen ist. Also kurze Frage: Was sind die genauen Cookieeinstellungen und welche Add-Ons sind diesbezüglich evtl. noch installiert/vorhanden?
-
OK, dann muss es bei mir noch mit anderen Erweiterungen zu tun haben. Denn mittlerweile findet mein "normaler" Firefox (101.0.1 unter Windows 11) auch keine offenen Tabs derselben Gruppe mehr... Anders kann ich mir dieses Verhalten jetzt leider nicht erklären (aber immerhin ist es identisch zum Nightly).
[...] Adressleiste sollte ausreichend sein, ansonsten ist der interne Name schon immer, seit die Adressleiste mehr kann als nur URLs, Awesomebar gewesen. [...]
Awesomebar - das merke ich mir ab jetzt. Da muss ich nämlich gleich an "Everything is awesome" aus "The Lego Movie" denken...
-
Hallo zusammen,
nachdem ich jetzt von Nightly auf Stable gewechselt bin, scheine ich damit (auch) keine Probleme mehr zu haben. Im Stable scheint die Funktion wie gewollt zu funktionieren. Dann bleibe ich ab jetzt wohl auf Stable und werde Nightly nur noch dann ausprobieren, falls ich spannende Neuerung vorab testen möchte.
Vielen Dank für die Antworten und viele Grüße!
-
Hallo zusammen,
ich habe eine Frage zu versteckten Tabs (hidden tabs): Wenn ich in der Firefox Omnibar (oder URL-Bar oder wie auch immer die Leiste genannt wird, in der man auch die URL eingibt) mittels "%" nach Tabs suche, finde ich keine Resultate, die versteckte Tabs (hidden tabs) betreffen. Wie kann ich auch in den versteckten Tabs nach einem Tab suchen, ohne oben über den "nach-unten-Pfeil" und dann auf "Hidden Tabs" zu klicken, sondern mithilfe der Suchfunktion für Tabs mittels "%" in der Omnibar?
Hintergrund: Ich nutze die Erweiterung "Simple Tab Groups" und habe mir darin verschiedene Gruppen gebaut, sodass nur die Tabs einer Gruppe angezeigt und die jeweils anderen Tabs versteckt werden. Dies ist aber nur eines von möglichen Setups - mit anderen Erweiterungen, die Tabs ebenso verstecken können, wird es das gleiche "Problem" bzw. die gleiche Fragestellung geben. Und ja, ich weiß, wie ich "Simple Tab Groups" selbst für die Suche nutzen kann (mache ich durchaus bereits).
Es würde mich allerdings interessieren, ob es bei versteckten Tabs überhaupt mittels der Suche in der Omnibar möglich ist, bei der Tab-Suche über "%" Tabs mit einzubeziehen, die versteckt sind...
Vielen Dank und viele Grüße!
-
-
Kurze Frage: Was bedeutet die folgende Passage im Detail?
Außerdem gab es noch eine Kompatibilitäts-Anpassung für Microsoft Teams.
-
Das Tool ist echt nett.
Nur die Übersetzungsleiste ist etwas unflexibel, bei mir muss ich den Browser breiter ziehen damit ich recht noch das Feld "Einstellungen" sehen kann.
Dann reich es doch am besten bei Mozilla als Bug oder dergleichen ein, damit es angepasst bzw. korrigiert werden kann...
-
-
Kurze Frage: Ist eine Integration in Fx für Android geplant? Oder dass man das Add-On wie z. B. uBlock Origin im Fx unter Android "nativ" installieren kann (ohne Collection etc.)?
-
Oh, interessant zu wissen, und schade, dass Mozilla nichts Derartiges hat. Danke für den Hinweis!
-
Synchronisierte Tabs gingen in Firefox noch nie von alleine auf.
Das kommt - glaube ich - darauf an, was man unter "synchronisierte Tabs" versteht. Wenn ich nur die Tabs synchronisiere, ohne sie explizit an ein anderes Gerät zu senden, gehen sie auch nicht auf einem anderen Gerät ("von alleine") auf. Wenn ich jedoch auf meinem Android-Handy einen Tab / eine Seite an ein anderes Gerät sende, geht dort in meinem Firefox ein neuer Tab mit der entsprechenden Seite auf.
yoshimo: Was genau versuchst du zu erreichen? Möchtest du einen Tab / eine Seite vom Mobilgerät auf den Desktop schicken, damit er dort weitergelesen werden kann? (So hätte ich deinen Post oben verstanden, wollte aber sicherheitshalber nochmal nachfragen...)
-
Ich bin mir ziemlich sicher, dass bei dir ein Blocker gegen Cookie Consent arbeitet. Sei es als Liste "i dont care about cookies" (inzwischen ein nutzloser Mist), oder die gleichnamige Erweiterung (ebenfalls Mist), oder "Consent Blocker".
Das kann ich übrigens nicht bestätigen. Ich habe auch "I don't care about cookies" als Erweiterung aktiv und kann mich problemlos damit beim Postbank Onlinebanking anmelden (aktuelle Nightly, aber sollte diesbezüglich hoffentlich keinen nennenswerten Unterschied machen).
rudi947: Welche Add-Ons hast du denn in deinem Firefox (-Profil) installiert? Hast du es mal mit einem neuen Profil (via about:profiles) probiert (einfach neues anlegen und in einem neuen Browserfenster öffnen)?
-
Boersenfeger: Meinst du ggf. https://status.services.mozilla.com/ (die wäre mir bekannt bzgl. Status der Services von Mozilla)? Diese URL wird derzeit mittels Response Code 301 auf https://www.mozilla.org/ umgeleitet.
-
Dann mal kurze Frage: Wie leerst / löschst du den Cache?
Chronik > Neueste Chronik löschen…
Beim Zeitraum wähle ich "Alles" und das Häkchen mache ich ausschließlich bei "Cache" rein, nirgends sonst.
Add-ons, die mit dem Cache irgendetwas zu tun haben, nutze ich keine.
Und egal, wie oft ich http://www.soeren-hentzschel.at/ (also unverschlüsselt) aufrufe, die Netzwerkanalyse zeigt ausnahmslos immer die Weiterleitung auf https an.
Hallo Sören,
aber das gleiche mache ich doch bei mir mit einem neuen Profil auch unter Schritt 2. oben. Daher verstehe ich nicht, wieso in dem neuen Profil der 301 nach dem Löschen des Caches bei mir nicht erscheint, bei dir aber wohl schon... ?! Ist mir unklar...
Falls jemand ebenfalls mal einen Test machen und hier kurz posten kann, wie es sich bei ihm verhält, wäre ich dankbar!
-
Ich habe den Cache alleine beruflich schon hunderte geleert, nur um Weiterleitungen zu testen. Und in ausnahmslos jedem Fall hat das bei mir funktioniert, dass die Weiterleitung damit aus dem Cache entfernt war.
Dann mal kurze Frage: Wie leerst / löschst du den Cache? Ich habe es mittels Strg+Shift+Entf (wie oben beschrieben) probiert, außerdem noch das AddOn "Clear Cache" genutzt. Letzteres hatte keinen Einfluss auf den nicht erscheinenden 301 Redirect.
Ich habe jetzt mal mein Vorgehen in einem erneut temporär neu angelegten Profil ohne AddOns oder sonstige about:config Änderungen mittels Screenshots "dokumentiert":
- Hier der erste Aufruf deiner Seite http://www.soeren-hentzschel.at (Redirect ist da):
- Dann löschen des Caches via Strg+Shift+Entf (Tab mit deiner Seite vorher geschlossen):
- Erneuter Aufruf deiner Seite (kein 301 Redirect zu sehen - aber hier ist auch der Cache in den Dev Tools nicht deaktiviert):
- Nochmal Leeren des Caches (vgl. 2).
- Erneut Aufruf deiner Seite (mit deaktiviertem Cache in den Dev Tools, wieder kein 301 Redirect zu sehen):
- Löschen aller Historie zu deiner Seite (Forget about this site):
+
- Erneuter Aufruf deiner Seite (ahhhh, wieder ein 301 Redirect):
Da ich leider nach wie vor nicht verstehe, was ich "falsch" mache beim Leeren / Löschen des Caches, wäre ich dir dankbar, wenn du mir kurz beschreibst, wie du es machst bzw. wie ich vorgehen kann, damit ich den 301 Redirect beim zweiten/dritten/... Aufruf deiner Seite ebenfalls sehe.
Bin da leider ein bisschen ratlos im Moment...
Noch ein Hinweis: Ich habe beim Löschen des Caches / der Historie (Schritte 2 und 4) auch mal alles andere an möglichen anklickbaren Optionen (in allen möglichen Konstellationen) durchprobiert. Nach meinem Empfinden hätte lediglich einmal (Zufall?) das Anhaken der Option "Browsing & download history" den 301 Redirect erscheinen lassen. Aber da das nicht reproduzierbar war und mir nur dauerhaft "Forget about this site" weitergeholfen hat, habe ich es erst mal (frustriert) dabei belassen. Wenn es natürlich auf irgendeine andere Weise viel einfacher und schneller geht (bin ein Freund von Keyboard Shortcuts), wüsste ich diese gerne. Lerne gerne dazu!
- Hier der erste Aufruf deiner Seite http://www.soeren-hentzschel.at (Redirect ist da):
-
Es gibt auch noch einen "HTTPS First"-Modus, der aber nur via about:config konfiguriert werden kann. Standardmäßig ist dieser in regulären Fenstern deaktiviert, in privaten Fenstern (oder wenn keine Chronik gespeichert wird), aktiviert. Möglicherweise hast du auch selbst in about:config mal was verstellt. In dem Fall kommt es natürlich auch zu keiner Weiterleitung, weil Firefox direkt HTTPS nutzt.
Ich habe in about:config diesen Punkt nicht verstellt. Der Boolean unter "dom.security.https_first" steht auf false.
Das hängt aber nicht mit der Chronik zusammen und doch, den Cache zu leeren, entfernt auch die Weiterleitungen aus dem Cache.
Tut mir leid, da muss ich leider deutlich widersprechen. Ich habe es mit einem blanken neuen Profil nachvollzogen und musste dabei Folgendes feststellen:
- Wenn ich mittels Strg+Shift+Entf den Cache zum Lösche auswähle und dabei "die letzte Stunde" als Zeitraum angebe (den Tab mit der Seite habe ich bereits vorher geschlossen), dann wird der 301-Redirect beim erneuten Aufruf nicht angezeigt.
- Wenn ich das gleiche mit "zwei Stunden" mache, erscheint das gleiche, kein Redirect, sondern direkt die HTTPS-Variante.
- Bei "vier Stunden" ebenso.
- Bei "heute" auch.
- Bei "Alles" hat es sich unterschiedlich verhalten. Beim ersten Mal schien es so, als wäre der Redirect-Cache geleert worden und er hat den Redirect wieder angezeigt. Nachdem ich nun aber nachvollziehen wollte, bei welchen "Historie-Löschen-Zeiträumen" der Redirect wieder kommt und die obigen bereits ausgeführt hatte, kann ich auch bei "Alles" den Redirect nicht mehr sehen.
Das Ganze habe ich mit einem nagelneuen Profil ohne jegliche AddOns oder sonstige manuellen Änderungen an about:config nachvollzogen. Erst beim Löschen der Historie für die Seite über "Forget this site" wird der Redirect __definitiv__ wieder angezeigt. Also reicht es nicht, nur den Cache zu leeren. Es gibt außerdem jede Menge Seiten, auf denen Leute Probleme mit dem Löschen des Caches und weiter existierender 301-Cacheeinträge zu haben scheinen, denn die Leute beschweren sich dort, dass das Löschen des Caches eben leider nicht den "Redirect-Cache" mit leert... (Daher habe ich auch den "Workaround" mit "Forget this site"...)
Die Entwicklerwerkzeuge zeigen außerdem Weiterleitungen an, auch wenn die Weiterleitung gecacht ist. Sollte das bei dir nicht der Fall sein, ist vermutlich entweder ein spezieller HTTPS-Modus aktiv oder auch hier spielt dir eine Erweiterung ein Streich.
Das muss ich leider auch verneinen, da ich es in dem obigen neuen blanken Profil definitiv nicht sehen konnte. Sogar bei Auswahl in den Entwicklerwerkzeugen, dass der Cache deaktiviert sein soll. Sobald einmal der 301-Redirect getan wurde, wird er nicht mehr angezeigt (außer bei Löschen über "Forget this site"). Wie bereits erwähnt sind hier keine AddOns aktiv, da temporär neues blankes Profil für Testzwecke erstellt.
-
Ich habe mittlerweile herausgefunden, dass ich den 301 Redirect nur bekomme, wenn ich die History lösche.
Eine ausführlichere Suche ergab dann, dass sich Leute vielerleiorts darüber ausgetauscht haben, dass es wohl neben dem "normalen" Cache (den ich zwischendurch über about:config sowohl für die Platte als auch für den Speicher (Disk+RAM) deaktiviert hatte) auch noch einen "speziellen 301-Redirect-Cache" gibt.
D.h. Firefox merkt sich in diesem Cache den 301-Redirect der von mir aufgerufenen Seite, selbst wenn ich Cache leere usw.
Am einfachsten kann man den 301-Redirect-Eintrag wohl aus dem "speziellen 301-Redirect-Cache" löschen, in dem man über Historie --> Seite suchen --> Diese Seite vergessen (Forget about this site) auswählt. Das entfernt dann wohl auch den im speziellen Cache gespeicherten Eintrag für den 301-Redirect.
Ach, und noch eins: Bei mir ist das "Temporary Containers"-AddOn dafür verantwortlich, dass die Entwickleroptionen sich schließen, sobald ich die erste URL aufrufe. Das liegt daran, dass im erstmaligen Aufruf einer Seite ein neuer temporärer Container erzeugt wird, und dabei werden die Entwickleroptionen geschlossen.
Nur, falls das jemandem auch mal so gehen sollte.
Danke für die Hilfe.
-
Danke erst einmal für die Antwort.
1. Das mit dem neuen Profil habe ich auch vorher bereits überlegt, aber bis dahin nicht die Zeit gehabt. Das habe ich jetzt nachgeholt. Dort konnte ich beim erstmaligen Aufruf einer der Webseiten den Redirect 301 sehen, allerdings nach Schließen des Browserfensters, Neu-Öffnen, usw. kam der Redirect 301 nicht mehr, also genauso wie in meinem Standardprofil. Als ich dann den Tab geschlossen und den Cache geleert habe, und danach das Ganze nochmal aufgerufen habe, kam der Redirect wieder.
Was aber __weiterhin__ nicht funktioniert, ist, dass in einem neuen Tab mit geöffneten Entwickleroptionen diese offen bleiben, sobald ich eine URL aufrufe. Im "sauberen"/neuen Profil ist das der Fall. Jetzt muss ich wohl oder übel mal auf die Suche gehen, welches meiner AddOns so etwas fabriziert...
2. Das mit den HTTP-Statuscodes ist mir klar. Firefox hat bei mir über verschiedene Wege eingestellt, die HTTPS-Variante anzufragen (und gar nicht erst die HTTP-Variante auszuprobieren). Das Interessante daran: Die Möglichkeiten eines "HTTPS-Upgrades" habe ich nach meinem Kenntnisstand allesamt für den Test ausgeschaltet (HTTPS-Only-Mode und HTTPS-Everywhere deaktiviert -- mehr wären mir derzeit nicht bekannt)...
-
Hallo zusammen,
ich untersuche die Response Header zu Websiteanfragen auf firmeninterne Websites, die eine HTTP-->HTTPS Umleitung via Status Code 301 bzw. 307 veranlassen. Dabei sind mir zwei Dinge aufgefallen, die ich gerne in der Runde erfragen wollte:
1. Bei einem neuen Tab habe ich die Entwickleroptionen via F12 geöffnet und direkt den Bereich "Netzwerk" ausgewählt (noch keine Seite in diesem Tab vorher geöffnet). Gebe ich nun die URL in die URL-Leiste ein und drücke Enter, schließen sich die Entwickleroptionen und meine gewünschte Analyse in einem "jungfräulichen" Tab kann ich erst einmal vergessen. Wenn ich dann die Entwickleroptionen erneut öffne und eine URL eingebe und aufrufe, werden die Anfrage und alle Ressourcen im Bereich Netzwerk ganz normal geladen/angezeigt, wie ich es erwartet hätte. Kann jemand dieses Problem bei einem nigelnagelneuen Tab bestätigen? (Zusatzinfo: Für einen neuen Tab nutze ich das AddOn Tabliss.)
2. Wenn ich die firmeninternen Websites mit dem serverseitig gesteuerten Redirect via Status Code 301/307 als HTTP-Seite aufrufe (mit geöffneten Entwickleroptionen), kann ich im FF den Redirect via 301/307 nicht sehen, sondern sehe als Erstes den Verbindungsversuch zur HTTPS-Variante (aber nix bzgl. Versuch auf HTTP-Variante und etwaige 301/307-Redirects). Den HTTPS-Only-Mode habe ich genauso ausgeschaltet wie das AddOn HTTPS-Everywhere, aber das Ergebnis ist das gleiche. In Chromium-basierten Browsern kann ich den Verbindungsversuch zur HTTP-Variante, dann den Redirect 301/307 und dann den Verbindungsaufbau zur HTTPS-Variante in Gänze nachvollziehen. Das Ganze geht dort übrigens auch z. B. bei http://www.google.de, http://maps.google.de, usw. Nur eben nicht in FF (oder nur für mich nicht ersichtlich). Mache ich hier irgendetwas falsch oder woran liegt das?
Danke für eventuelle Antworten!
