Instantbird unterstützt zahlreiche Netzwerke, darunter ICQ, MSN, Jabber/XMPP, Facebook, Google Talk, Yahoo!, IRC und noch einige mehr. Da Instantbird auf Mozilla-Code aufsetzt, finden sich hier auch aus Firefox und Thunderbird bekannte Komponenten wie der Add-on Manager, über welchen sich gewohnt einfach Add-ons und Themes installieren lassen, wovon es derzeit insgesamt über 300 auf der offiziellen Erweiterungsseite gibt. Gerade Nutzer von Thunderbird dürften sich vertraut vorkommen, da Thunderbirds Instant Messaging-Funktionalitäten aus Instantbird portiert worden sind. Instantbird ist aktuell in 14 Sprachen, darunter auch Deutsch, für die Betriebssysteme Windows, Mac OS X sowie Linux verfügbar.

Die neue Version 1.4 basiert auf auf der Gecko 20-Codebasis von Mozilla (Version 1.3: Gecko 16) und auf der aktuellsten libpurple-Version 2.10.7. Durch die Verwendung von Gecko 20 läuft Instantbird ab sofort nicht mehr auf Systemen mit Mac OS X 10.5 und auf Computern mit PowerPC-CPU.

Zu den Neuerungen von Instantbird 1.4 gehören ein verbesserter Zeichenzähler für Twitter, welcher nun auch URLs in den Tweets korrekt berücksichtigt. Die Twitter-API wurde außerdem auf Version 1.1 aktualisiert, damit Twitter auch nach dem 11. Juni 2013 noch über Instantbird benutzt werden kann – an diesem Tag wird Twitter die alte Version 1.0 der API abschalten.

Die Verlaufs-Ansicht wurde überarbeitet und organisiert die Gesprächsverläufe nach Datum und verschachtelt diese nach Wochen, Monaten etc. Ungültige, selbst signierte und abgelaufene Zertifkate können für IRC-Konten nun überschrieben werden. Außerdem gibt es eine bessere Unterstützung für IRC-Bouncer.

In der Welt rund um Mozilla passieren viele spannende Dinge; es vergeht praktisch kaum ein Tag, ohne dass nicht auf irgendeiner Webseite ein lesenswerter Artikel zu einem aktuellen Mozilla-Thema erscheint. Ein Großteil der Themen wird durch diesen Blog abgedeckt, doch bieten auch andere Webseiten nicht minder spannende Artikel, zu nennen seien hier unter anderem die großen Portale Golem, Heise, Winfuture, Pro-Linux, Computer Bild oder Computerbase – um nur eine Auswahl zu nennen.

Auf der anderen Seite gibt es mit Social Media heute eine tolle Möglichkeit, Inhalte mit möglichst vielen Menschen in der Welt zu teilen. Ich habe ein neues Projekt ins Leben gerufen, welches diese Möglichkeit mit den Neuigkeiten rund um Mozilla verbinden möchte. Mit dem Ziel, den Leser bestmöglich zu informieren, auch abseits dieses Blogs.

Mit diesem Artikel kündige ich offiziell die Facebook-Seite, die Google Plus-Seite sowie die Twitter-Seite zu mozilla.de an. Wer diesen drei oder zumindest einem dieser drei Sozialen Kanäle folgt, sollte in Zukunft keine wichtige Meldung mehr verpassen, welche sich um Mozilla dreht.

HINWEIS: Bei diesem Service handelt es sich um kein offizielles Angebot von Mozilla, der Inhalt wird von mir alleine gepflegt. Natürlich findet sich hier nicht jeder im Internet existierende Artikel, dafür ist jeder einzelne der dort verlinkten Artikel von mir überprüft, ob er seriös ist und keine groben inhaltlichen Fehler beinhaltet.

Im Übrigen freue ich mich auch über Zuwachs auf den Sozialen Kanälen zu diesem Blog (Facebook, Google Plus, Twitter). Beide Angebote ergänzen sich, ersetzen sich aber nicht gegenseitig. Während die neuen mozilla.de-Kanäle auf spannende Artikel auf allen möglichen Webseiten in deutscher Sprache verlinken, beziehen sich die Sozialen Kanäle dieses Blogs zwar, was Artikel betrifft, ausschließlich auf diesen Blog, werden dafür immer wieder mit spannenden Zusatz-Informationen versorgt, welche es weder in diesen Blog schaffen noch auf andere Webseiten zu finden sind. Es lohnt sich also beiden zu folgen.

Hier noch einmal alle Kanäle in der Übersicht:

mozilla.de auf Facebook
mozilla.de auf Google Plus
mozilla.de auf Twitter

soeren-hentzschel.at auf Facebook
soeren-hentzschel.at auf Google Plus
soeren-hentzschel.at auf Twitter

Wer den vollen Installationspfad seiner installierten Plugins erfahren möchte, stellt üblicherweise über about:config den Schalter plugin.expose_full_path auf true. Anschließend kann der Installationspfad der Plugins über die Seite about:plugins abgelesen werden. Dies kann vor allem dann nützlich sein, wenn man unerwünschte Plugins loswerden möchte, welche sich beinahe überall auf dem System verstecken können.

Ein Fehler in der aktuellen Firefox 21-Version sorgt allerdings dafür, dass dies nicht funktioniert – Firefox zeigt unter keinen Umständen mehr den Plugin-Pfad an. Dabei handelt es sich um keine gewünschte Änderung, ab Firefox 22 (als Beta-Version erhältlich) wird der vollständige Plugin-Pfad wieder auf dieser Seite angezeigt.

Eine bewusste Änderung gibt es mit Firefox 22 dann aber neben der Behebung dieses Problems doch: Die Seite about:plugins zeigt dann nämlich unabhängig vom Wert des Schalters plugin.expose_full_path immer den vollen Plugin-Pfad an und wird von dieser Einstellung losgelöst.

Was bedeutet dies für den Endanwender? Dieser sollte plugin.expose_full_path grundsätzlich auf false stehen haben, da der Plugin-Pfad bei aktiviertem Schalter über navigator.plugins durch JavaScript für alle Webseiten auslesbar ist, was als Sicherheits-Risiko einzustufen ist! Zum Ablesen des vollständigen Plugin-Pfades ist das Umkippen dieses Schalters nicht länger notwendig.

Vor ziemlich genau einem Jahr habe ich einen Rundgang durch den Firefox Marketplace, welcher damals noch nicht öffentlich zugänglich war, durchgeführt. Im September mit dem Start der Testphase für Android und Firefox OS habe ich den Firefox Marketplace dann für Mobilgeräte gezeigt. Nun erstrahlt der Firefox Marketplace in ganz neuem Glanz. Da Bilder mehr als 1000 Worte sagen, lasse ich die folgende Bildergalerie für sich sprechen.

Und so sieht der Firefox Marketplace auf dem Smartphone aus:

Wie immer gilt auch bei dieser Anleitung: Verwendung auf eigene Gefahr.

Da die PHP 5.3 Version für die Nutzung mit mod_fcgid selbst kompiliert werden muss, stellen wir zuerst einmal sicher, dass wir die benötigten Pakete zum kompilieren installiert haben.
Davon, dass die grundlegenden Programme zum Kompilieren von Quellcode (z. B. gcc) installiert sind, gehe ich an dieser Stelle einmal stillschweigend aus.

apt-get install libapache2-mod-fcgid apache2-suexec libpcre3-dev libpcre++-dev libpng12-dev libbz2-dev libcurl4-openssl-dev libc-client2007e-dev libjpeg-dev libgif-dev libgif4 libpthread-stubs0 libpthread-stubs0-dev libx11-dev libxau-dev libxcb1-dev libxdmcp-dev libxpm-dev x11proto-core-dev x11proto-input-dev x11proto-kb-dev xtrans-dev libxml2-dev libmysqlclient-dev libfreetype6-dev

Als nächstes laden wir uns die aktuelle Version des PHP Quellcodes. Zum Zeitpunkt dieses Artikels war die aktuellste Version 5.3.25.

cd /tmp
wget "http://de.php.net/get/php-5.3.25.tar.bz2/from/this/mirror" -O php.tar.bz2
tar xjf php.tar.bz2
cd php-5.3.25

Nach dem Entpacken und Wechseln in das Quellcode-Verzeichnis kommt es beim Kompilieren nun darauf an, ob wir eine 64Bit oder eine 32Bit Installation von Debian verwenden.

server1:~# uname -a
Linux server1 2.6.30-2-amd64

In meinem Fall ist das System also mit einem 64Bit Kernel ausgestattet, wenn dort i386 oder i686 statt des amd64 steht kann man davon ausgehen, dass eine 32Bit Version installiert ist.

Kompilier-Befehl für 32Bit:

./configure --prefix=/usr/share/php53 --datadir=/usr/share/php53 --mandir=/usr/share/man --bindir=/usr/bin/php53 --with-libdir=lib --includedir=/usr/include/php53 --sysconfdir=/etc/php53/apache2 --with-config-file-path=/etc/php53/apache2 --with-config-file-scan-dir=/etc/php53/conf.d --enable-libxml --enable-session --with-pcre-regex=/usr --enable-xml --enable-simplexml --enable-filter --disable-debug --enable-inline-optimization --disable-rpath --disable-static --enable-shared --with-pic --with-gnu-ld --with-mysql --with-gd --with-jpeg-dir --with-png-dir --with-xpm-dir --enable-exif --with-zlib --with-bz2 --with-curl --with-ldap --with-mysqli --with-freetype-dir --enable-soap --enable-sockets --enable-calendar --enable-ftp --enable-mbstring --enable-gd-native-ttf --enable-bcmath --enable-zip --with-pear --with-openssl --with-imap --with-imap-ssl --with-kerberos --enable-phar --enable-pdo --with-pdo-mysql --with-mysqli

Kompilier-Befehl für 64Bit:

./configure --prefix=/usr/share/php53 --datadir=/usr/share/php53 --mandir=/usr/share/man --bindir=/usr/bin/php53 --with-libdir=lib/x86_64-linux-gnu --includedir=/usr/include/php53 --sysconfdir=/etc/php53/apache2 --with-config-file-path=/etc/php53/apache2 --with-config-file-scan-dir=/etc/php53/conf.d --enable-libxml --enable-session --with-pcre-regex=/usr --enable-xml --enable-simplexml --enable-filter --disable-debug --enable-inline-optimization --disable-rpath --disable-static --enable-shared --with-pic --with-gnu-ld --with-mysql --with-gd --with-jpeg-dir --with-png-dir --with-xpm-dir --enable-exif --with-zlib --with-bz2 --with-curl --with-ldap --with-mysqli --with-freetype-dir --enable-soap --enable-sockets --enable-calendar --enable-ftp --enable-mbstring --enable-gd-native-ttf --enable-bcmath --enable-zip --with-pear --with-openssl --with-imap --with-imap-ssl --with-kerberos --enable-phar --enable-pdo --with-pdo-mysql --with-mysqli

Beim Vorbereiten der Kompilierung von PHP fehlt auf 64bit Maschinen eine Abhängigkeit, es kommt zu einer Fehlermeldung ähnlich wie dieser:
configure: error: Cannot find imap library (libc-client.a). Please check your c-client installation.
Um dies zu korrigieren reicht ein kleiner Befehl vor dem Kompilieren:

ln -s /usr/lib/libc-client.a /usr/lib/x86_64-linux-gnu/libc-client.a

Der einzige Unterschied zwischen den Kompilierbefehlen besteht eigentlich darin, dass bei der 64Bit-Variante bei der Option –with-libdir einen anderen Pfadnamen übergeben bekommt.
Die weiteren Optionen stellen sicher, dass die PHP Version später auch IMAP, MySQL (inkl. PDO), GD (Grafikbibliothek), Curl und ein paar weitere Module enthält.

Wenn der configure Befehl ohne Fehler beendet ist, kann das Kompilieren und Installieren durch die Befehlsfolge

make
make test # optional
make install

gestartet werden.
Der Befehl make test ist optional, sollte aber vor der Installation verwendet werden um sicherzustellen, dass PHP korrekt kompiliert wurde.

Nach der Installation befindet sich in /usr/bin/php53/ nun ein eigenes Verzeichnis für die PHP Binaries der Version 5.3.25.
Nun müssen wir noch sicherstellen, dass die Apache-Module mod_fcgid (Fast-CGI) und SuExec aktiv sind.

a2enmod fcgid
a2enmod suexec
/etc/init.d/apache2 force-reload

Als nächstes erstellen wir uns eine Starter-Datei für PHP als Vorlage für unsere Web-User. Was genau eine solche Datei tut, darüber wurde an anderen Stellen schon so viel geschrieben, dass ich mir die Erläuterungen hier spare. Eine Google Suche nach PHP FCGI wird sicherlich einige Ergebnisse bringen.
Natürlich bieten diese Skripte oft noch einige Funktionen, die an dieser Stelle bewusst weggelassen wurden. Hier wird wirklich nur eine minimale Version verwendet.

mkdir -p /etc/php53/php-fcgi
vim /etc/php53/php-fcgi/php-starter

Der Inhalt der Datei:

#!/bin/sh

FCGID_STARTER_PHPBIN="/usr/bin/php53/php-cgi -c /etc/php53/cgi/"

exec $FCGID_STARTER_PHPBIN

Nach dem Speichern versehen wir die Datei mit den passenden Zugriffsrechten und setzen danach das Immutable Bit. Dadurch sind keine Änderungen mehr an der Datei möglich (auch nicht durch root-User), bis das Immutable Bit wieder gelöscht wird.

chmod 750 /etc/php53/php-fcgi/php-starter
chattr +i /etc/php53/php-fcgi/php-starter

Damit sind die Vorbereitungen abgeschlossen.
Was nun folgt sind die Einstellungen für die einzelnen Webs, für die die neue PHP Version aktiviert werden sollen.
Wir gehen hier davon aus, dass das Web in /var/www/webseite liegt.
Zunächst erstellen wir (falls noch nicht vorhanden) einen User mit dem Namen “webuser” als Besitzer des Webs.

useradd -d /var/www/webseite -s /bin/false webuser

Nun erstellen wir (falls noch nicht vorhanden) ein Verzeichnis für die FCGI Starterdatei und kopieren die vorbereitete Starterdatei dorthin.

mkdir -p /var/www/fcgi/webseite
cp -a /etc/php53/php-fcgi/php-starter /var/www/fcgi/webseite/
chown -R webuser:webuser /var/www/fcgi/webseite
chattr +i /var/www/fcgi/webseite/php-starter

Das Verzeichnis könnte auch anders heißen, wichtig ist nur, dass es innerhalb von /var/www liegt, da sonst suexec keinen Zugriff darauf erlaubt.
Das Verzeichnis sollte jedoch nicht über den Browser erreichbar sein.

Nachdem die Vorlagendatei in das Webverzeichnis kopiert wurde und die korrekten Dateirechte vergeben wurden, muss nun noch die Einstellung für den Apache VHost der Webseite gemacht werden.

SuexecUserGroup webuser:webuser
<FilesMatch \.php$>
    SetHandler fcgid-script
</FilesMatch>

AddHandler fcgid-script .php .php4 .php5
FCGIWrapper "/var/www/fcgi/webseite/php-starter" .php
FCGIWrapper "/var/www/fcgi/webseite/php-starter" .php5
FCGIWrapper "/var/www/fcgi/webseite/php-starter" .php4

Eigentlich war es das schon und das Web sollte auf PHP 5.3.25 laufen.
Durch die Umstellung kann es sein, dass PHP keinen Zugriff mehr auf zuvor von PHP angelegte Dateien hat. Dies liegt dann daran, dass der Besitzer von Dateien, die mit PHP (mod_php) angelegt wurden www-data als Besitzer haben, da PHP als Apache Modul unter diesem Benutzer ausgeführt wird.
In der hier eingerichteten Variante wird PHP mit SuExec als “webuser” ausgeführt.

Man kann sehr einfach alle Dateien finden, die www-data gehören und den Besitzer ändern:

cd /var/www/webseite
find /var/www/webseite -user www-data -exec chown webuser:webuser {} \;

Zum Testen der PHP Version ist es am einfachsten eine einfache PHP Datei in das Web-Verzeichnis zu legen, die nur den folgenden Inhalt hat:

<?php
phpinfo();
?>

Falls beim Aufruf dieser Datei im Webbrowser noch die falsche PHP Version angezeigt wird oder ein Fehler 500 auftritt, oder der Apache sich nicht starten lässt hilft es die Fehlermeldungen in den Logdateien zu lesen.
Die wichtigsten Meldungen sind hierbei im SuExec Log (/var/log/apache2/suexec.log) und im Apache Log (/var/www/webXY/log/error.log) zu finden.
Der häufigste Fehler sind fehlerhafte Berechtigungen der php-starter Datei, die zu einem Streik von SuExec führen.

Wie Mozillas CTO Brendan Eich in seinem Blog schreibt, wird sich das geänderte standardmäßige Verhalten in Bezug auf Drittanbieter-Cookies verschieben. Ursprünglich war es geplant, Cookies von Drittanbietern standardmäßig zu blockieren, sofern es sich dabei um keine Seite handelt, welche vom Benutzer zuvor besucht worden ist. Während diese Änderung ganz im Sinne der Nutzer sein dürfte, handelte sich Mozilla im Vorfeld viel Kritik seitens der Werbetreibenden dafür ein. Nichstdestominder möchte Mozilla weiter an diesem Plan festhalten und die Änderung später bringen. Derzeit gebe es aber noch Probleme mit der aktuellen Umsetzung zu lösen, welche eine längere Testphase erforderlich machen.

Die überarbeitete Einstellung im Datenschutz-Panel des Einstellungs-Dialogs wird wie gehabt mit Firefox 22 ausgeliefert werden und kann somit von den Nutzern angewendet werden, nur für eine standardmäßige Aktivierung der neuen Einstellung in Firefox 22 ist es für die breite Masse noch zu früh. So kann es in seltenen Fällen derzeit noch dazu kommen, dass Drittanbieter-Cookies blockiert werden, welche nicht blockiert werden sollen, beispielsweise bei der Nutzung von Content-Delivery-Networks (CNDs). Umgekehrt könnten Drittanbieter-Cookies nicht blockiert werden, welche blockiert werden sollen. Mozilla will die Funktionsweise weiter verfeinern, ehe die neue Einstellung standardmäßig aktiv wird. In den Aurora- und Nightly-Versionen bleibt die Einstellung wie bislang auch standardmäßig aktiviert.

Mozilla zeigt derzeit intensive Bemühungen, den Datenschutz seiner Nutzer weiter zu verbessern. So wurde mit dem vorgestern veröffentlichten Firefox 21 die Einstellung für Do-not-Track verbessert – einem HTTP-Headerfeld, welches Webseiten signalisieren soll, ob der Benutzer zu Werbe- oder Analyse-Zwecken getrackt werden möchte oder nicht. Mit einer der nächsten Firefox-Versionen werden standardmäßig alle Drittanbieter-Cookies von Webseiten blockiert, welche der Benutzer zuvor nicht besucht hat. Und im Juni wird Mozilla die Version 1.0 des Add-ons Collusion veröffentlichen, eine Erweiterung, welche das Tracking durch Webseiten visualisiert. Die neue Version zeigt sich gegenüber der vor über einem Jahr vorgestellten Version deutlich verbessert.

Collusion 1.0 soll es deutlich einfacher machen, die Kontrolle zu behalten. Die neue Version wird nicht mehr nur zu sehen erlauben, welche Seite einen verfolgt, sondern zeigt auch Informationen zum Standort dieser Seite an und lässt einen Schritte unternehmen, das Tracking durch diese Seite zu deaktivieren. Collusion 1.0 erlaubt sowohl das Blockieren als auch das Whitelisten von Trackern. Außerdem erstrahlt Collusion 1.0 in vollkommen neuem Glanz und kommt mit einer weiteren Visualisierung daher, nämlich der Darstellung der Verbindungen nach Uhrzeiten, wobei zwischen Seiten unterschieden wird, welche aktiv besucht worden sind und Drittanbieter-Seiten. Eine Listen-Ansicht zeigt alle von Collusion gesammelten Daten. Die Daten können außerdem anonym mit einer öffentlichen Datenbank geteilt werden, über die Collusion-Webseite können die öffentlichen Visualisierungen dann von anderen angesehen werden.

Video auf popcorn.webmadecontent.org ansehen

Bislang ändert Mozilla die Versionsnummern von Firefox und Thunderbird ausschließlich an der ersten und der dritten Stelle. Für die ESR-Versionen möchte man in Zukunft den Vorteil der zweiten Versionsstelle nutzen. Konkret soll parallel zu beispielsweise Firefox respektive Thunderbird 25 die dann veröffentlichte ESR-Version anstelle der Versionsnummer 24.0.1 die Versionsnummer 24.1 tragen. Dadurch sollen sich die ESR-Veröffentlichungen leichter mit den dazugehörigen Mainstream-Veröffentlichungen in Verbindungen bringen lassen. Außerplanmäßige Updates verändern in diesem Modell wie bislang auch die dritte Versionsstelle.

Für Erweiterungs-Entwickler bedeutet dies, dass sie die maximale Kompatibilität ihrer Add-ons immer beispielsweise im Format 24.* anstelle von 24.0.* angeben sollten, was besonders bei Erweiterungen mit Binärkomponenten relevant ist, welche keine standardmäßige Kompatibilität besitzen.

Neue Standard-Schriftarten für bessere Lesbarkeit

Ab Version 21 nutzt Firefox als Standardschrift für Web-Content nicht länger die mit Android ausgelieferten Schriftarten, sondern liefert mit Charis (Serif) und Open Sans (Sans Serif) nun selber welche mit. Bei beiden Schriftarten handelt es sich selbstverständlich um Open Source-Schriftarten. Diese sind besonders für das Lesen auf kleinen Bildschirmen optimiert und sollen das Lesen auf dem Smartphone respektive Tablet einfacher machen.

Verbessertes Design

Wie auch schon mit Firefox Mobile 20 wurde auch in Version 21 das Design des Mozilla-Browsers weiter verbessert und dabei Texturen und Icons entfernt, um damit nicht zuletzt auch die Performance weiter zu verbessern. Das zuvor dunkle Kontextmenü sowie Einstellungen kommen nun in einer hellen Farbe daher.

Sonstige Verbesserungen

Durch ein langes Drücken der Zurück-Taste des Gerätes ist es ab sofort möglich, aus der aktuellen Chronik des jeweiligen Tabs, eine zuvor besuchte Seite auszuwählen und so vor- und zurückzunavigieren. Für HTML5-Video und -Audio gibt es einen neuen Menüeintrag durch langes Drücken auf das Video oder den Audio-Titel, was einem erlaubt, die Mediendatei herunterzuladen statt abzuspielen. Das lange Drücken eines Vorschaubildes auf der Startseite ermöglicht es nun, eine einzelne Webseite von der Startseite zu entfernen. Der StageFright-Decoder zum Abspielen von H.264 wurde mit Firefox Mobile 21 für weitere ältere Geräte- und Systemkombinationen freigeschaltet, nämlich für LG-Geräte mit Android 2.2, für HTC-Geräte mit Android 2.3, für einige Samsung-Geräte mit Android 2.3 sowie für Samsung-Geräte mit Android 3. Außerdem ist es nun für andere Anbieter möglich, eigene Versionen von Firefox Mobile mit vordefinierten Einstellungen, Lesezeichen sowie Themes auszuliefern, ähnlich wie man es bereits vom Desktop-Firefox unter anderem mit der MSN-Version kennt.

Dazu kommen wie üblich diverse Fehlerbehebungen, geschlossene Sicherheitslücken und Plattform-Verbesserungen, was auch eine verbesserte Unterstützung von Webstandards wie die des HTML5 <main>-Elements einschließt. Das auf mobilen Webseiten häufiger eingesetzte -moz-user-select:none verhält sich nun außerdem wie das entsprechende Pendant von Webkit, IE und Opera. Zu den nennenswerten Fehlerbehebungen gehört, dass der Download-Manager nach dem Löschen der Privaten Daten nicht mehr neu geladen werden muss, damit die vorhandenen Downloads aus der Liste entfernt werden, und dass In-Content-Bildschirme wie der Add-on Manager auf Geräten mit kleinen Bildschirmen nicht länger abgeschnitten werden.

Der ursprüngliche Plan von Mozilla sah vor, die Add-on-Leiste von Firefox zu entfernen. Add-ons sollten ihre Symbole dann in der Navigationssymbolleiste platzieren. Nachdem einige Nutzer diesbezüglich große Bedenken geäußert haben, hat man auch bei Mozilla erkannt, dass dieses Vorhaben nicht funktionieren kann, da Erweiterungen ohne Probleme ziemlich viel Platz für sich beanspruchen können. Statt die Add-on-Leiste zu entfernen wird sie nun also auch in Zukunft ein Ort sein, an welchem Erweiterungen Platz finden und als Fläche für das Anpassen der Symbolleisten dienen kann. Diskutiert wird allerdings noch, ob die Add-on-Leiste nach oben wandern wird, wie das folgende Mockup zeigt, oder nicht.

Bildquelle: people.mozilla.com/~mferretti