The Quote is pasting the previously highlighted text if clicked multiple times

Yes, I could repeat this when I follow the steps (in Firefox). Even though I almost never select text using a keyboard, just the mouse... I think it's more to do with not fully clearing text in the insertAtCursor function after clicking on the bold, etc. button.

I could just expect so far, it's about another method of selection... and it's in another function, not in insertAtCursor.

Do you have alternative habits of how to highlight the text, except with the keyboard like I provided?.. perhaps double/triple clicking the text or similar.

In most cases, I use text highlighting with a mouse. But when I write something in a form, I use a delete/backspace buttons too. I often write some text, then use the Bold or Italic button on some selected text (I then may use the Shift + array button to select the text I need). So this combination may cause the issue..

After more tests, I could conclude that the issue is in form.js — getSelectionText() function and two event listeners — 'mouseup' and 'touchend'.

These codes are responsible for the mouse operations. When the left button is hold, the text is selected and then the left button is released, the code remembers the start and end position of the selected text. This data is used later when calculating what portion of text should be surrounded by a certain BB-code.

If you select some text with the mouse, then click Delete or Backspace button to delete it, the text is still kept in memory as being selected, and is not reset to an empty state. That's why if after that any BB-code button is clicked, the deleted text will appear between BB-code-tags.

insertAtCursor() function appears to work properly, 'cause it resets selektionEvent value to an empty after any BB-code is applied.

But with the getSelectionText() function there's a dilemma... I could possibly code additional events with catch delete/backspace, but it's not really universal method — selected text could be deleted inserting or pasting another text over it.

So, the question actually remains — how to properly reset the selection to an empty value, without affecting the other text manipulations.

So, for the Delete/Backspace events, you can try to add the following to form.js — let me know if it worked:

— Above document.addEventListener('mouseup', function(){ add the following function:

— Above function insertAtCursor... add the following:

That probably should fix 90% of cases when the selection is not reset — but now it will be after Delete or Backspace keyboard's button pressed.

I have customized form scripts, but I tested it on a non-customized site and it seems to work (even though from my experience it appeared randomly so I wouldn't be surprised that I encounter this problem again). But for now it works, I tested only in Firefox.

I've also played with an example JS concept like below from AI and for now I don't see a problem, even though I'm not very active at posting right now:

Whatever I could be sure at this stage — it could not be a random issue, it has an algorithm in background, which you have just to catch and follow.

captureAndResetSelection() is not truly about how miniBB operates on BB buttons/codes, but the basics are similar. Still, it's not a solution to the issue discussed here.

I've tried to follow the example, and cannot get it to go wrong.
Paul, have you added the above .js code to apply that fix?

Steve

Yes, it's added here on these forums, and I see you have also added it to your forums, so at least good to know the part of the issue is fixed (I'll bring it to the new release of miniBB which I'm working on).

The miniBB demo forums are still not updated with the .js additional code, and for a while you can repeat the issue there as described above.

There's also an update of the function handleKeyDown(event) I've released today. The function doesn't need myField.focus(); code as it generated the JS error; and also now it contains events for the Shift + Left/Arrow keys combination. I'm mostly sure now this function could handle 99% of the wrong cases appearing earlier.

I wonder if there's a test step to repeat the problem (I could then test it in Firefox as it's not widely used and confirm it works or not..).

If form.js is updated with the codes provided above in post #20, I suppose it wouldn't be easy to repeat the problem... what I've suggested definitely fixes some cases, but they could be more.

My random testings in Firefox with all possible cases I could find work well..

I have still found one bug when the selection is done using Shift + Left | Right arrow keys. If the text is selected that way and then f.e. the Bold button clicked, then:

— if the Shift + LEFT arrow key pressed, the first char from the
— if the Shift + RIGHT arrow pressed, the last char from the right is removed.

ChatGPT explanation:

So... The updated code for the function is as follows by now:

BTW I've checked the current version of form.js (which is now updated also here on this forum), and it also properly handles selection of the Shift + Home | End buttons combination.