[3.0] Theme split (wave 4, part 24) — drop the caret shim and the resizer the editor never had

[albertlast]

Description

Part of the effort to break #7933 into reviewable pieces. This one takes the posting area's share of the editor markup that does nothing.

Every editor on the forum — posting, personal messages, newsletters, anything using template_control_richedit() — emits its textarea with four inline handlers:

onselect="storeCaret(this);" onclick="storeCaret(this);" onkeyup="storeCaret(this);" onchange="storeCaret(this);"

storeCaret() reads document.selection.createRange(), which was IE's API, and guards itself with 'createTextRange' in oTextHandle. Neither exists in any browser SMF supports, so the function has been a no-op for years. It also cannot be reached at all: SCEditor replaces that textarea and leaves it display: none, so none of the four events ever fire on it. The only other consumer of what it stored, the caretPos branch in replaceText(), is guarded the same way and is equally unreachable. Nothing else in the tree calls it, so the function goes with the handlers.

The <div id="<editor>_resizer" class="richedit_resize"> beside it is in the same state: nothing styles .richedit_resize and nothing looks up that id — not in this theme, and not in 2.1 either, where the same empty div is emitted. It renders as a box of zero height.

Both are gone in the #7933 tree, which is where this comes from.

Deliberately left alone

The hidden <editor>_mode field looks equally dead, and today it is: nothing sets it client-side, and Editor::$rich_active no longer reads it. But in 2.1 it was read (Subs-Editor.php, !empty($_REQUEST[$editorOptions['id'] . '_mode'])) so that an editor left in WYSIWYG mode came back in WYSIWYG mode after a preview or a failed post. That behaviour is currently lost, and removing the field would foreclose restoring it, so it stays for whoever picks up the editor work.

The dead caretPos branches inside replaceText() and surroundText() stay too, matching the #7933 tree.

How this was tested

On a local 3.0 install:

• The posting form was measured through an iframe before and after: .sceditor-container, .sceditor-toolbar, the button row, the attachments area and the page height are all identical to the pixel. The only difference is that the resizer div is no longer there.
• The editor still initialises and round-trips its value (sceditor.instance(textarea).val(...)), with all 34 toolbar buttons present and nothing on the console.
• Swept the pages that draw an editor — new topic, reply, new poll, send personal message — each still builds its .sceditor-container, with no element left carrying an onselect and no .richedit_resize anywhere.

Issues References (Fixes|Related|Closes)

Related: #7933