…m running.

Lexical's onClick handler implements a triple-click handler that is
trivial/anemic/naïve. The intention of the change, made in
facebook/lexical#4512, seems to be to deal with browsers'
"overselection" behavior, where a triple-click selection might end at
offset 0 of the following block, which can cause issues when
transforming the selection. But the implementation breaks many common
real-world use cases.

An upstream bug report was filed in June 2025 for this behavior:

    facebook/lexical#7592

Just to name two common impacted scenarios that are top-of-mind:

- triple-clicking in a paragraph with soft line breaks (`<br>` tags)
- triple-click-dragging to select multiple lines

The specific motivating reason for Lexical's handler seems to be that
the "Header" tool in Lexical doesn't handle this overselection and
will header-ify the following line; and that table cells can be
deleted entirely once selected.

However, Lexxy has its own "Header" tool that doesn't have this issue;
and Lexical tables no longer exhibit the cell-deletion behavior. I
think it might be better to improve the formatting tool(s) than to
hack the selection mechanism.

Hopefully, we can remove this once Lexical addresses this
behavior. Some possible upstream approaches for that might be:

- Move the existing selection handling logic into a real handler that
  applications can pre-empt.
- Fix the selection behavior, or drop the triple-click handler
  completely.

ref: https://app.basecamp.com/2914079/buckets/41746046/card_tables/cards/9861391060

…m running.

Lexical's onClick handler implements a triple-click handler that is
trivial/anemic/naïve. The intention of the change, made in
facebook/lexical#4512, seems to be to deal with browsers'
"overselection" behavior, where a triple-click selection might end at
offset 0 of the following block, which can cause issues when
transforming the selection. But the implementation breaks many common
real-world use cases.

An upstream bug report was filed in June 2025 for this behavior:

    facebook/lexical#7592

Just to name two common impacted scenarios that are top-of-mind:

- triple-clicking in a paragraph with soft line breaks (`<br>` tags)
- triple-click-dragging to select multiple lines

The specific motivating reason for Lexical's handler seems to be that
the "Header" tool in Lexical doesn't handle this overselection and
will header-ify the following line; and that table cells can be
deleted entirely once selected.

However, Lexxy has its own "Header" tool that doesn't have this issue;
and Lexical tables no longer exhibit the cell-deletion behavior. I
think it might be better to improve the formatting tool(s) than to
hack the selection mechanism.

Hopefully, we can remove this once Lexical addresses this
behavior. Some possible upstream approaches for that might be:

- Move the existing selection handling logic into a real handler that
  applications can pre-empt.
- Fix the selection behavior, or drop the triple-click handler
  completely.

ref: https://app.basecamp.com/2914079/buckets/41746046/card_tables/cards/9861391060

…m running. (#1050)

Lexical's onClick handler implements a triple-click handler that is
trivial/anemic/naïve. The intention of the change, made in
facebook/lexical#4512, seems to be to deal with browsers'
"overselection" behavior, where a triple-click selection might end at
offset 0 of the following block, which can cause issues when
transforming the selection. But the implementation breaks many common
real-world use cases.

An upstream bug report was filed in June 2025 for this behavior:

    facebook/lexical#7592

Just to name two common impacted scenarios that are top-of-mind:

- triple-clicking in a paragraph with soft line breaks (`<br>` tags)
- triple-click-dragging to select multiple lines

The specific motivating reason for Lexical's handler seems to be that
the "Header" tool in Lexical doesn't handle this overselection and
will header-ify the following line; and that table cells can be
deleted entirely once selected.

However, Lexxy has its own "Header" tool that doesn't have this issue;
and Lexical tables no longer exhibit the cell-deletion behavior. I
think it might be better to improve the formatting tool(s) than to
hack the selection mechanism.

Hopefully, we can remove this once Lexical addresses this
behavior. Some possible upstream approaches for that might be:

- Move the existing selection handling logic into a real handler that
  applications can pre-empt.
- Fix the selection behavior, or drop the triple-click handler
  completely.

ref: https://app.basecamp.com/2914079/buckets/41746046/card_tables/cards/9861391060

…le-click workaround

Fixes facebook#7592.

\## Context

Browsers expand triple-click selections to cover an entire block, but
leave the focus point at offset 0 of the *next* block. The selection
visually looks like one paragraph is selected, but actually extends
one position into the following block.

Historically, this selection behavior caused some issues, including:

- facebook#2648 Converting to other
  blocks after selection (e.g. Heading)
- facebook#2660 Over-selection
- facebook#3784 Selections have
  incorrect format
- and another bug with table cell select-and-deletion mentioned in facebook#4512

PR facebook#4512 worked around these bugs in `onClick` (`LexicalEvents.ts`) by
detecting `event.detail === 3` and forcibly re-selecting the parent
block..

The `onClick` workaround is a poor fit, however, because it mutates
the user's selection on *every* triple-click — breaking common cases
like triple-clicking a paragraph with soft line breaks:(`<br>`), or
triple-click-and-drag to select multiple lines, leading to issues like
the one described in facebook#7592

\## Status of the original motivations

A lot has changed since facebook#4512!

- Table cell deletion was fixed independently in facebook#7213; the tables no
  longer rely on the `onClick` workaround.
- facebook#2660 No longer manifests without the triple-click handler
- facebook#3784 No longer manifests without the triple-click handler
- facebook#2648 The heading format tool (and related tools — paragraph, quote,
  code block — all routed through `$setBlocksType`) is the only
  remaining caller depending on the workaround.

Which means the triple-click handler can be removed if
`$setBlocksType` is updated to handle overselection.

\## This change

Fix `$setBlocksType` (`@lexical/selection`) to skip converting the
focus's block when no content of that block is actually selected —
specifically, when the focus is a text-type point at offset 0 of the
block's first descendant and the block differs from the anchor's
block. This matches the visual semantics users expect, and covers both
triple-click overselection and deliberate
drag-select-to-start-of-next-block.

With that root cause fixed, the `onClick` triple-click workaround is
removed.

\## Tests

- Existing e2e tests for triple-click + heading conversion continue
  to pass without the `onClick` workaround
  (`Selection.spec.mjs`, `TextFormatting.spec.mjs`).
- `$setBlocksType` unit tests in
  `packages/lexical-selection/src/__tests__/unit/LexicalSelection.test.tsx`
  continue to pass; the fix only affects text-type focus points, so
  the existing element-point-based tests are unchanged.