[Bug] automatisiertes Setzen von [QUOTE]-Blöcken

Piktogramm

Fleet Admiral
Registriert
Okt. 2008
Beiträge
10.031
Gerade gefunden, man beginne eine neue Zeile mit einem "Größer als" und das Forum löscht eben jenes Zeichen und setzt einen QUOTE-Block

Testfälle:

[QUOTE]=0[/QUOTE]

Code:
[QUOTE]=0[/QUOTE]


Testfälle als Bild beim Verfassen als Vergleich:
805659


PS: Bekomm ich jetzt ein Eis?
Ergänzung ()

Weitere Tests
größer null:
kleiner gleich null:
<=0
gleich null:
=0
größer größer null
 
Zuletzt bearbeitet:
Danke für die Meldung! Die Bearbeitung wird ein wenig dauern. @Steffen hat Urlaub ;)
 
Ich habe gerade selbst versucht im Xenforo Forum einen Bugreport zu schreiben. Der Bug ist in deren Forum nicht replizierbar, ich spare mir den Bugreport daher. Ich gehe davon aus, dass das Problem in neueren Versionen gefixt wurde.
 
Kann ich nach einem Test in unserem Xenforo basierten Forum bestätigen - das "Grösser als" führt auch bei uns zu einem Quote Block.

Forentest.jpg
 
@Smurfy1982
Passt!

@areiland
Da XenForo Pseudomarkdown zu BB parst ist das ja noch ein halbwegs akzeptables Verhalten. Auf Mailinglists werden Zitate ja auch mit > am Zeilenanfang markiert. Entsprechend setzt XenForo das sogar recht gut um. Doof ist vor allem das sich das A nicht vom Nutzer abstellen lässt und B auch in CODE-Blöcken erfolgt(e).



Beispiel https://lkml.org/lkml/2019/8/5/416 im Xenforo:
On 8/4/19 11:23 AM, Artem S. Tashkinov wrote:
Hello,

There's this bug which has been bugging many people for many years
already and which is reproducible in less than a few minutes under the
latest and greatest kernel, 5.2.6. All the kernel parameters are set to
defaults.

Steps to reproduce:

1) Boot with mem=4G
2) Disable swap to make everything faster (sudo swapoff -a)
3) Launch a web browser, e.g. Chrome/Chromium or/and Firefox
4) Start opening tabs in either of them and watch your free RAM decrease

Once you hit a situation when opening a new tab requires more RAM than
is currently available, the system will stall hard. You will barely be
able to move the mouse pointer. Your disk LED will be flashing
incessantly (I'm not entirely sure why). You will not be able to run new
applications or close currently running ones.

This little crisis may continue for minutes or even longer. I think
that's not how the system should behave in this situation. I believe
something must be done about that to avoid this stall.

Yeah that's a known problem, made worse SSD's in fact, as they are able
to keep refaulting the last remaining file pages fast enough, so there
is still apparent progress in reclaim and OOM doesn't kick in.

At this point, the likely solution will be probably based on pressure
stall monitoring (PSI). I don't know how far we are from a built-in
monitor with reasonable defaults for a desktop workload, so CCing
relevant folks.

I'm almost sure some sysctl parameters could be changed to avoid this
situation but something tells me this could be done for everyone and
made default because some non tech-savvy users will just give up on
Linux if they ever get in a situation like this and they won't be keen
or even be able to Google for solutions.


Best regards,
Artem


################################

Experimente:

"> foobar" sollte ein Quote ohne ">" werden:

"\\>foobar\\"[1] sollte ein iCODE mit ">" werden
>foobar

"\\\>foobar\\\" [1] sollte ein CODE mit ">" werden
>foobar

"\>foobar" sollte zu ">foobar" ohne Quote-Block werden

\>foobar

\foobatz



[1] Also laut Doku: https://enterprise.github.com/downloads/en/markdown-cheatsheet.pdf sollte ein Backslash ja ein backtick escapen können, macht es aber nicht...
Das war es mir jetzt doch wert ein Bug bei XenForo zu posten :D https://xenforo.com/community/threads/markdown-escaping-backticks-with-backslash.168449/
 
Zuletzt bearbeitet:
Laut XenForo ist es kein bekannt/gewollt, dass Markdown nur halbherzig unterstützt wird.

Parser die Escapesequenzen nur halbherzig umsetzen reizen mich ja irgendwie...
 
Zurück
Oben