Clipboard "table" paste parser splits on \n only — Excel's \r\n leaves a stray \r on the last column and adds an empty trailing row

[massynico]

Note: this issue was drafted with the help of Claude (Claude Code). The root-cause analysis and the suggested fix were verified against the current source and against live behaviour in 6.3.1.

Description

The built-in table clipboard paste parser splits pasted data on \n only and does not handle \r\n line endings. When pasting data copied from Excel (and most Windows apps), which ends rows with \r\n and adds a trailing \r\n after the last row, two problems occur:

1. The \r from each \r\n stays attached to the value of the last column of every row (e.g. a pasted y1 becomes "y1\r").
2. The trailing \r\n produces an extra empty trailing row, which — depending on clipboardPasteAction — either inserts a blank row or overwrites the cell below the target with an empty value.

This is the same underlying problem reported long ago in #2489, which was closed without a fix (no reproducible example was provided at the time). It still reproduces on 6.3.1 / current master.

Steps to reproduce

1. A table with clipboard: true.
2. Copy a 2×2 range from Excel — clipboard content is x1\ty1\r\nx2\ty2\r\n.
3. Paste into the table.

Expected

[["x1","y1"],["x2","y2"]] — clean values, no stray \r, no extra empty row.

Actual

Parser produces [["x1","y1\r"],["x2","y2\r"],[""]] — \r stuck on the last column of each row, plus a trailing empty row.

Root cause

src/js/modules/Clipboard/defaults/pasteParsers.js, the table parser:

clipboard = clipboard.split("\n");   // only \n; \r\n and trailing newline not handled
clipboard.forEach(function(row){
    data.push(row.split("\t"));
});

Suggested fix

Normalize line endings and drop a single trailing blank line before splitting:

clipboard = clipboard.replace(/\r\n?/g, "\n").replace(/\n$/, "");

For reference, ag-Grid handles this in its clipboard parser by treating \r\n as a single line break (skipping the \n after a \r) and removing a trailing blank line (suppressLastEmptyLineOnPaste → removeLastLineIfBlank).

Environment

• Tabulator 6.3.1 (also present on current master)
• Any browser

[tevinch]

Two useful regression cases for this fix are a quoted cell containing a newline and a genuinely empty final cell. A global newline replacement also changes CRLF inside a quoted cell; trimming the whole input removes meaningful trailing tabs/spaces.

For applications needing a workaround, the documented clipboardPasteParser callback can return row objects or false for invalid input. I maintain a small MIT-licensed clipboard TSV parser that handles the record terminator separately from quoted cell content. Copy its index.mjs and LICENSE into a local clipboard-table directory; this example is for two columns (x, y), without a header row:

import { parseClipboard } from "./clipboard-table/index.mjs";

function pasteXY(clipboard) {
  try {
    const rows = parseClipboard(clipboard);
    if (!rows.length || rows.some(row => row.length !== 2)) return false;
    return rows.map(([x, y]) => ({ x, y }));
  } catch {
    return false;
  }
}

// In your existing Tabulator options, with fields named x and y:
// clipboard: true,
// clipboardPasteParser: pasteXY,
// clipboardPasteAction: "insert",

These assertions pass against that callback:

import assert from "node:assert/strict";

assert.deepEqual(pasteXY("x1\ty1\r\nx2\ty2\r\n"), [
  { x: "x1", y: "y1" }, { x: "x2", y: "y2" },
]);
assert.deepEqual(pasteXY('001\t"line 1\r\nline 2"\r\n'), [
  { x: "001", y: "line 1\r\nline 2" },
]);
assert.deepEqual(pasteXY("x1\t\r\n"), [{ x: "x1", y: "" }]);
assert.deepEqual(pasteXY("x1\ty1\r\n\t\r\n"), [
  { x: "x1", y: "y1" }, { x: "", y: "" },
]);
assert.equal(pasteXY('x1\t"unclosed'), false);
assert.equal(pasteXY("x1\ty1\textra"), false);

This deliberately uses fixed fields: it does not reproduce the built-in parser's header detection or the separate range-paste behavior. I verified the parser and callback in Node; I have not validated this workaround in a live Tabulator browser instance. For an upstream fix, these cases may still be useful without taking an external dependency.