In WebKit, Auto-Close Brackets plugin creates incorrect text

[WebCoder49]

This is a problem for me only in GNOME Web and not in Firefox/Chromium, but it may be a problem in other WebKit-based browsers (if you use another WebKit-based browser* please let me know if you can reproduce the error).

* e.g. the Free Emacs or Konqueror, or the proprietary Apple Safari, non-EU iOS any browser, Amazon Kindle; some embedded systems

Steps to reproduce

code-input version 2.5.0.

• Run either prism.html or hljs.html in the test file in this repo under GNOME Web
• Optionally type some code then go onto a new line.
• Either type some code before the caret (option a), some whitespace before the caret (option b), only newlines before the caret (option c) or nothing (option d).
• Type an opening bracket ((/[/{) (option e) or a double quote (") (option f)

Expected behaviour

A closing bracket or other quote appears after the caret, as occurs in Gecko (Firefox) and Blink (Chromium). The opening bracket still appears typed as normal.

Actual behaviour

Option combination	Result
a e	Expected behaviour matched, except when an identical closing bracket is after the caret initially, in which case no other closing bracket is not added (it's as if the automatically-inserted closing bracket is being caught by the keydown event which allows closing brackets to be overwritten).
b e	The end of the whitespace changes to ")(" while the caret stays visibly in the same position.
c e or d e	The closing bracket appears but no opening bracket that should have been typed appears.
a f or b f	After a delay, a large number of quotes appear, the caret moves after the first of them and a "RangeError: Maximum call stack size exceeded" error appears in the console, referencing document.execCommand on line 44 of auto-close-brackets.js.
c f	A single double quote appears, with the caret after it. The same console error is logged.
d f	A single double quote appears, with the caret before it. The same console error is logged.

[WebCoder49]

It appears the document.execCommand("insertText") code may be triggering the beforeinput event amd thus recursively the checkBrackets function as the browser simulates a keypress.

Using a flag to prevent the events being handled when execCommand is running fixes all of the cases EXCEPT FOR b e, c e, d e and d f. See the referenced commit above.

Aside: I know that execCommand is officially deprecated but there is no other browser-native way to automatically input text in an undoable fashion, and execCommand is only used in plugins and not code-input's core.

[WebCoder49]

I can reproduce this same behaviour after the flag is used on macOS Safari.

[WebCoder49]

Removing the blur and focus calls which have been problematic in other places doesn't fix this.

[WebCoder49]

The close-bracket processing was attached to the beforeinput event. The problem remaining was that the character was being input before the beforeinput event in Chromium and Gecko, but after it in WebKit. Changing the event to input fixed this and made the character always be input before.