Fixed Inline code not working correctly

[BassMan]

Affected version

2.2.12

When trying to use inline code I get this result:







It happens here and on my test forum on 2.2.12 in Safari and Firefox.

 

[Kruzya]

Can’t reproduce on Firefox. Maybe this related with browser?

 

[BassMan]

I checked in Firefox too and the same issue for me. And it does not happen on 2.2.11.

 

[Mr Lucky]

I get that on Safari

test
test
test

However, would you normally have a line break before inline code?

 

[BassMan]

Also this:







Result:

 

[BassMan]

However, would you normally have a line break before inline code?

No.

 

[Black Tiger]

Same problem here with Firefox (did not test with others)

Linebreak before and after shouldn't happen and did not happen before (older versions).

 

[Recep Baltaş]

Oh god! Thought I was the only one!

Tested in Chrome and same! Inline code should be in the line, not under and on top.

 

[Nicolas FR]

Same bug for inline spoiler...

 

[Max Taxable]

I saw it was working fine here and don't know why. I'm using newest chrome on Android 12.

 

[Xon]

I believe this is the result of a bugfix where injecting tags which wrap new lines would get the editor into a bad state. I think it isn't handling newlines when the selected text is the entire line.

 

[Black Tiger]

Just now I see lots of new posts in "resolved bugs", I hope this will also be fixed somehow in the new 2.2x version?

 

[Chris D]

So for reasons that do not make sense to me, I have tracked it down to this line:

selectedHtml = ed.html.getSelected();

If you have this editor content:

<p>test test test</p>

And you select only the middle test the result of ed.html.getSelected() is:

<p>test</p>

The end result being what we insert into the editor is:

[ICODE]<p>test</p>[/ICODE]

Which will look like this:

[ICODE]
test
[/ICODE]

The behaviour somewhat makes sense - after all, if the actual editor content looked like this:

<p><strong>test test test</strong></p>

You would want the selection to include <strong> because otherwise that formatting could be lost (depending on what you're doing with the selection).

We did use a different approach in 2.2.11 but that had other issues:

Fixed - Editor insertSpoiler does not correctly handle formatting

When using the 'insert spoiler' (and bb-code which uses wrapSelectionText) this can result in unexpectedly broken bb-code. Given this bb-code in the rich-text editor: line1 line2 line3 line4 Drag-select line2/line3, and select insert spoiler. This will result in the following html: line1

xenforo.com

At this point it feels tempting to just remove the outer <p></p> if we're working with an inline tag, as we are here.

I hate working with this editor.

 

[Chris D]

 

[TPerry]

You are probably old enough to get this.. but it's a certain time.

Either into submission.. or into non-existence!

 

[Black Tiger]

I don't know how it works or what causes it. I can just select any tekst, also in your lines also.

I can only just type some words like this and then select and put into icode.

and the same happens instantly, very odd. You can see it on the little block icode on top of the line.

I hate working with this editor.

I believe you instantly, I hear more people about that editor.

 

[Xon]

I hate working with this editor.

ed.html.getSelected is a buggy mess and behaves differently depending on the browser. It has some questionable behavior as you've discovered around the entire-line selection.

I published my work-around for the behavior you've documented in this post. I think this is the 4th or maybe 5th iteration of patching how XF.EditorHelpers.wrapSelectionText works because Froala is just hard to work with.

At least this version I haven't had to patch since February!

At this point it feels tempting to just remove the outer <p></p> if we're working with an inline tag, as we are here.

I think that is really the only sane thing todo in this stage.

 

[Black Tiger]

behaves differently depending on the browser.

This is an interesting thing.

Since you say "depending on the browser", could it have caused this issue too since 2.2.7?

Fixed - Using 2 Emoji's in a Row on Firefox

Since updating to XF 2.2.7 when using 2 emoji's in a row the second one will start a new line. Using Windows 10 and Firefox 92.0. Checked here and confirmed it happens.

xenforo.com

This not only happens on 1 row, if you place a bunch of text, go back to the first line, and then add some smilies, the first get on the next line, the rest totally even on the bottom of the alinea instead of the next line, so very odd.

There is some discussion about it being a browser issue, which could be the case, but then why not before 2.2.7 and maybe it's the same cause as the icode issue, so who knows.

 

[Chris D]

I published my work-around for the behavior you've documented in this post. I think this is the 4th or maybe 5th iteration of patching how XF.EditorHelpers.wrapSelectionText works because Froala is just hard to work with.

At least this version I haven't had to patch since February!

I missed that workaround.

I just implemented it and, while it helps with this issue, what actually happens now is this is inserted (in Safari and Firefox):

test <p>[ICODE]test[/ICODE]</p> test

So it produces:

test
[ICODE]test[/ICODE]
 test

 

[Xon]

This is an interesting thing.

Since you say "depending on the browser", could it have caused this issue too since 2.2.7?

Froala has a bunch of dubious per-browser-type behavior that is hard to troubleshoot. It wouldn't surprise me if it was related.

I missed that workaround.

I just implemented it and, while it helps with this issue, what actually happens now is this is inserted (in Safari and Firefox):

It adds a 5th parameter to wrapSelectionText the inline flag. Did you patch the [icode] (and [ispoiler]) handler to set that 5th argument so it strips out the <p> tag?