mühsames Markieren von Text

  • Firefox-Version
    103.0
    Betriebssystem
    Linux

    Hallo zusammen

    Wenn ich auf folgender Website Text markieren will, dann verschwindet die Markierung wieder, wenn der Mauszeiger zu weit nach rechts (Edit:) nach links geht und ich muss von vorne beginnen.

    Das Gleiche passiert, wenn ich zu schnell und zu weit nach oben gehe mit dem Mauszeiger.

    Site: https://www.investopedia.com/articles/inves…can-economy.asp

    Hier eine Gif-Animation:


    Um zu schauen, ob dies etwas mit Firefox zu tun hat, habe ich das Selbe mit Vivaldi ausprobiert.

    Resultat: Dort passiert das nicht.

    Frage:

    -Könnt ihr das Verhalten nachvollziehen? Oder habt ihr keine solchen Probleme?

    -Wen ja: Woran liegt es?

    Besten Dank.

    Gruss

    Bafire

    Einmal editiert, zuletzt von Bafire (28. Juli 2022 um 14:10)

  • Bafire 28. Juli 2022 um 13:58

    Hat den Titel des Themas von „frickeliges markieren“ zu „mühsames markieren von Text“ geändert.
  • Bei mir verschwindet weder in die eine noch in die andere Richtung die Markierung. Wie bei Andreas wird dann auch anderer Text mit markiert.

    Zum Warum: Nun, irgendwas muss die Website sehr unkonventionell gelöst haben. Denn unabhängig davon, ob Firefox sich unter den hier vorliegenden und mir unbekannten Voraussetzungen vielleicht besser verhalten könnte: Andere Websites verhalten sich ja nicht so.

    Der Workaround ist aber recht einfach: Beim Markieren im Textblock bleiben. Man muss die Maus ja nicht nach außen bewegen. Es braucht schon ein ganzes Stück, damit es zu einer ungewollten Markierung kommt. Ein paar Pixel verursachen das noch nicht. ;)

  • Vielen Dank fürs Ausprobieren. :)

    Achtung: Ihr müsst schon GENAU die Textpassage verwenden, die in der Gif-Animation gezeigt wird.

    Und zwar soll dann in dieser Textpassage von unten nach oben markiert werden. (Also von unten mit der Markierung beginnen.)

    2002Andreas
    Sorry. In Post 1 habe ich "rechts" mit "links" verwechselt. Ist aber inzwischen korrigiert/editiert.

  • Habe es mehrmals gemacht wie du es forderst. Es ist so wie @Sören geschrieben hat: bleibt man mit der Maus in der Nähe des Textes, bleibt die Markierung erhalten. Entfernt man sich, so wie du in deinem Video, zu weit, geht die Markierung verloren.

    MfG
    Geldhügel

  • Der Workaround ist aber recht einfach: Beim Markieren im Textblock bleiben.

    Es ist so wie @Sören geschrieben hat: bleibt man mit der Maus in der Nähe des Textes, bleibt die Markierung erhalten. Entfernt man sich, so wie du in deinem Video, zu weit, geht die Markierung verloren.

    Allerdings.
    Der Workaround funktioniert natürlich.

    Einmal editiert, zuletzt von Bafire (29. Juli 2022 um 08:48)

  • Danke für die Nachfrage.

    Die Idee wäre es gewesen, die Tabelle zu markieren und dann mit einem Web-clipper addon auszuschneiden und z.B. als Markdown oder HTM File zu speichern.

    Aber mir fällt einfach grundsätzlich immer wieder auf, dass es beim Markieren ein unerwartetes Verhalten gibt in Firefox. (Nicht nur in Tabellen). Früher war das nicht so (vor 15-20 Jahren).

    Einmal editiert, zuletzt von Bafire (12. Juli 2023 um 18:51)

  • Ja, kann sein, dass es an der Komplexität der modernen Seiten liegt.


    Edit:

    Vielleicht doch nicht.

    Vivaldi verhält sich bezüglich Markierung in diesem Fall benutzerfreundlicher:

    GitHub - Rooyca/MarkOb-Obsidian-Highligter: Highlight your text and send it to your Obsidian vault. It automatically creates you a file with the name of the page.
    Highlight your text and send it to your Obsidian vault. It automatically creates you a file with the name of the page. - GitHub -…
    github.com

    3 Mal editiert, zuletzt von Bafire (12. Juli 2023 um 17:18) aus folgendem Grund: Ein Beitrag von Bafire mit diesem Beitrag zusammengefügt.

  • Bei Edge funktioniert das ebenso, über alle "Spalten" den Text zu markieren. Bei Firefox, auch der aktuellen 102 ESR, kann man nur die ersten zwei Spalten richtig markieren, sobald man mit der Maus in eines der Felder in der dritten Spalte gerät, ist es vorbei, dann wird da willkürlich was markiert. In der dritten Spalte selbst kann man nur genau ein Feld markieren. Alles sehr merkwürdig.

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!

  • Ja, kann sein, dass es an der Komplexität der modernen Seiten liegt.


    Edit:


    Vielleicht doch nicht

    Vivaldi verhält sich bezüglich Markierung in diesem Fall benutzerfreundlicher:

    Das eine schließt das andere nicht aus. Browser müssen heute ein Vielfaches von dem unterstützen, was sie vor 20 Jahren unterstützen mussten. Entsprechend komplex sind heutige Rendering-Engines. Da sprechen wir mittlerweile von Millionen Zeilen an Code. Natürlich wachsen mit zunehmender Komplexität auch die Unterschiede zwischen den Rendering-Engines, wo eine Engine ein bestimmtes Szenario vielleicht besser löst als eine andere Engine.

    Bis Fx 68 hat es auch noch im Fx funktioniert, danach nicht mehr :/

    Du weißt, was das heißt: mozregression. ;)

  • last good

    Code
    app_name: firefox
    build_date: 2020-01-20
    build_file: C:\Users\...\.mozilla\mozregression\persist\2020-01-20--mozilla-central--firefox-74.0a1.en-US.win64.zip
    build_type: nightly
    build_url: https://archive.mozilla.org/pub/firefox/nightly/2020/01/2020-01-20-15-44-12-mozilla-central/firefox-74.0a1.en-US.win64.zip
    changeset: 59873ee30955167ac1c6cc1eaafcbeda834ef74d
    pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=59873ee30955167ac1c6cc1eaafcbeda834ef74d&tochange=79514ae28ef4b3508baf56fc8e89ef593a9b77b1
    repo_name: mozilla-central
    repo_url: https://hg.mozilla.org/mozilla-central

    first bad

    Code
    app_name: firefox
    build_date: 2020-01-21
    build_file: C:\Users\...\.mozilla\mozregression\persist\2020-01-21--mozilla-central--firefox-74.0a1.en-US.win64.zip
    build_type: nightly
    build_url: https://archive.mozilla.org/pub/firefox/nightly/2020/01/2020-01-21-21-52-03-mozilla-central/firefox-74.0a1.en-US.win64.zip
    changeset: 79514ae28ef4b3508baf56fc8e89ef593a9b77b1
    pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1c9b97bed37830e39642bfa7e73dbc2ea860662a&tochange=79514ae28ef4b3508baf56fc8e89ef593a9b77b1
    repo_name: mozilla-central
    repo_url: https://hg.mozilla.org/mozilla-central

    Dazwischen werden nicht genügend Daten mehr gefunden.

    Das interessanteste, was mir noch aufgefallen ist, bis last good wird das Datum absolut angezeigt, "April, 3,2023", bei first bad als relativ "3 months ago". Ob das nun von Firefox kommt, sich mit einem Schalter zurückschalten lässt, oder ob ein Javascript von github dazu richtiger abgearbeitet wird, mir unbekannt. Ich kann mit dem pushlog nicht viel anfangen.

    Eben noch gefunden

    https://github.githubassets.com/assets/node_modules/@github/relative-time-element/dist/relative-time-element.js

    Ab Zeile 86.

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!

    Einmal editiert, zuletzt von .DeJaVu (15. Juli 2023 um 15:13)

  • Dazwischen werden nicht genügend Daten mehr gefunden.

    Stimmt, das ergibt auf Grund des Alters Sinn. Die Nightly Builds bleiben zwar für immer bestehen, aber alle Builds dazwischen werden nach einem gewissen Zeitraum aus Platz-/ Kostengründen gelöscht. Ich weiß jetzt nicht, wie lange dieser Zeitraum ist, aber hier sprechen wir von über drei Jahren, das ist definitiv zu alt…

    Das interessanteste, was mir noch aufgefallen ist, bis last good wird das Datum absolut angezeigt, "April, 3,2023", bei first bad als relativ "3 months ago". Ob das nun von Firefox kommt, sich mit einem Schalter zurückschalten lässt, oder ob ein Javascript von github dazu richtiger abgearbeitet wird, mir unbekannt.

    Die Seite verwendet an dieser Stelle ein Custom Element und JavaScript-APIs wie Intl.DateTimeFormat und Intl.RelativeTimeFormat, deren Unterstützung nicht von Anfang an komplett war, sondern im Laufe der Zeit erweitert worden ist. Also Teile der Webplattform, die „relativ modern“ sind. Das dürfte also weniger mit einem Schalter in Firefox oder damit zu tun haben, ob GitHub etwas „richtiger“ abarbeitet, als viel mehr damit, dass ab einem gewissen Punkt Firefox einfach zu alt ist und mindestens einen genutzten Webstandard in der Version noch nicht unterstützt.

  • Bis Fx 68 hat es auch noch im Fx funktioniert, danach nicht mehr :/

    Das ist nicht richtig; hier werkelt noch Version 91.13.0ESR, (weil sie stabiler daherkommt und die Seiten ruckelfreier wiedergibt als 102*.*ESR), und das Markieren auch mit der Maus klappt wunderbar.

    Vielleicht bedarf es dafür des Ankreuzens des "Markieren von Text mit der Tastatur zulassen" Feldes unter "Surfen" im Bereich "about:preferences - Allgemein"? Dieses Feld ist hier standardmäßig angekreuzt.

  • Das ist nicht richtig; hier werkelt noch Version 91.13.0ESR, (weil sie stabiler daherkommt und die Seiten ruckelfreier wiedergibt als 102*.*ESR

    Deine Sicherheit sowie deiner Mitmenschen ist dir also völlig egal. Die Verwendung einer dermaßen alten Firefox-Version ist absolut indiskutabel. Zumal deine Begründung höchst zweifelhaft ist. Firefox 91 ist ganz sicher nicht performanter als Firefox 102, im Gegenteil. Mittlerweile sind wir übrigens bei Firefox ESR 115. Bitte hole schnellstmöglich eine Aktualisierung deines Firefox nach. Würde es tatsächlich Probleme geben, die nicht nur als Ausrede vorgeschoben sind, könntest du ein Thema hier im Forum eröffnen, wo man versuchen würde, dir zu helfen. Aber das weißt du ja.

    Zum Thema zurück: Ich hatte kürzlich selbst mozregression ausgeführt und die Regression-Range von .DeJaVu stimmt. Ich hatte das dann nur nicht weiter verfolgt, aus genau dem von ihm genannten Grund, dass keine weitere Eingrenzung möglich war. Sprich: Das Problem besteht seit Firefox 74.