kontexmenü eEinträge verschieben sich ständig ?

  • (Reparier bitte den Titel.)


    jedesmal wenn ich RMT klicke verschieben sich die Einträge im kontexmenü des Firefox 57.0.2 (64-Bit) für Windows 7.

    kann man das irgendwie unterbinden ?


    RMT?

    Du bist nicht allein damit. das ärgert noch andere (mich inbegriffen). Ich hatte auch schon beobachtet, dass aktualisierte und vorübergehend deaktivierte Addons plötzlich am Ende auftauchen. Ein paar Zitate aus General discussions, feedback, questions belong here (v3) · Issue #88 · Aris-t2/CustomCSSforFx · GitHub (Quintessenz daraus im separaten Folgeposting):

    rayman89 am 17.12.:

    Zitat


    With #tabContextMenu menuitem[label="New Tab"] { -moz-box-ordinal-group: 0 !important; } I was able to put a context menu item at top but I was not able to select the order of the following menu items. For example I wanted foxy tab to be second I tried #tabContextMenu menuitem[label="FoxyTab"] { -moz-box-ordinal-group: 1 !important; } but it did nothing.

    Is it possible to set foxy tab to the second place?

    Daraufhin Aris:

    Ich musste auch meinen Senf dazugeben:

    Zitat von Speravir


    I think it’s simply the accidental addon loading order.


    worauf Aris antwortete:

    Zitat von "ArisCTR" user_id=89109


    The startup caches also affect the menu in some way. After moving many items inside the menu with "-moz-box-ordinal-group", they refuse to restore their initial position automatically after removing the code tweaks.

  • Quintessenz: Man kann die Reihenfolge beeinflussen, indem man so etwas in die userChrome.css einträgt – noch einmal das Beispiel von Aris (wobei Ich ID bevorzugen würde, unten gleich mehr dazu):


    Dass dort immer „-moz-box-ordinal-group: 0 !important;“ ist kein Fehler, sondern pure Absicht, so muss man nicht zählen; der folgende Eintrag überschreibt immer den vorherigen, aber soeben bereits eingelesenen. Die so eingestellte Reihenfolge scheint irgendwo gespeichert zu werden, denn sie bleibt (wenigstens bei Aris) auch noch eine Weile erhalten, wenn man die Einträge wieder entfernt hat.

    Für das Kontextmenü des Inhaltsbereiches ist das durchaus aufwendig, weil man eine größere Menge an Einträgen zu beachten hat – inklusive Trennlinien (Element menuseparator) und zeitweise ausgeblendeten Einträgen, die aber für den Fall, dass sie eingeblendet werden, berücksichtigt werden müssen. Die anderen Kontextmenüs habe ich mir noch nicht angesehen.

    Anstelle der Label, die sich von Sprache zu Sprache unterscheiden und vor allem auch mal ändern können, würde ich lieber die ID nutzen, das ist robuster. (Siehe jedoch Update!) Man muss sowieso kontrollieren, ob es sich um menu oder menuitem handelt (na ja, hinter einem menu dürfte ein weiteres Untermenü lauern; anderseits ist bei einer ID die Angabe des Elementnamen eventuell gar nicht notwendig). Dazu, wie man die ID herausfinden kann, siehe Andreas' Hilfe in Re: Inspector für Kontextmenü.

    Update:[/i]
    Äähm, das ist aber blöd. Eine Reihe von Addons, die sich im Kontextmenü eintragen, machen anscheinend keine Vorgabe für die ID. Für sie wird dann der Hashwert als ID verwendet, wie er auch für den Namen des Addons oder Unterordners in "<Profilordner>/extensions" genutzt wird (die geschweiften Klammern {} und @ werden dabei durch _ ersetzt) – und zusätzlich nach einem Unterstrich ein zufälliger Wert, der sich bei jedem Start ändert! Man wird ziemlich schnell feststellen, dass diese Addons sich nicht an die Sortierungsvorgabe halten wollen. Für diese Addons ist die Variante von Aris dann wohl die bessere. Es gäbe noch die Möglichkeit, nur eine markante Teilzeichenkette der ID anzugeben, etwa so:

    CSS
    #contentAreaContextMenu menuitem{id*="$Hashwert-ID_ohne_Zahlenwert_am_Ende$"] {
      -moz-box-ordinal-group: 0 !important;
    }