Repository navigation
In WebKit, Auto-Close Brackets plugin creates incorrect text #131
Description
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. |
Activity
Fix infinite recursion (bug unfixed - see #131)
WebCoder49 commentedon Jun 27, 2025
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 commentedon Jun 28, 2025
I can reproduce this same behaviour after the flag is used on macOS Safari.
[-]In GNOME Web only (maybe other WebKit e.g. Apple Safari too), Auto-Close Brackets plugin creates very strange text[/-][+]In WebKit only, Auto-Close Brackets plugin creates very strange text[/+][-]In WebKit only, Auto-Close Brackets plugin creates very strange text[/-][+]In WebKit only, Auto-Close Brackets plugin creates incorrect text[/+][-]In WebKit only, Auto-Close Brackets plugin creates incorrect text[/-][+]In WebKit, Auto-Close Brackets plugin creates incorrect text[/+]WebCoder49 commentedon Jul 14, 2025
Removing the
blurandfocuscalls which have been problematic in other places doesn't fix this.WebCoder49 commentedon Jul 15, 2025
The close-bracket processing was attached to the
beforeinputevent. The problem remaining was that the character was being input before thebeforeinputevent in Chromium and Gecko, but after it in WebKit. Changing the event toinputfixed this and made the character always be input before.Fix AutoCloseBrackets and Indent across WebKit and others (Fixes #131, …