AvaloniaEdit Issues to date

El catálogo solicitado es AvaloniaEditWorkaroundsAndIssues.md; empieza por revisar las pull requests de ILSpy enumeradas y los archivos de soluciones provisionales enlazados. Verifica cada entrada con el texto del issue, especialmente el estado upstream, y termina con una lista Markdown que registre el comportamiento, la ubicación de la solución provisional, el PR que la introdujo y si todavía vale la pena informar del problema upstream.

Intent: catalogue all problems we had & fixed to be able to properly report upstream (and keep tabs on what has been fixed since.

Prompt: Search our pull requests since April this year for AvaloniaEdit workarounds, eg https://github.com/icsharpcode/ILSpy/pull/4252. Give me a list with details as AvaloniaEditWorkaroundsAndIssues.md so that I can later decide to report them in the AvaloniaEdit repository so they get properly fixed upstream.

AvaloniaEdit workarounds and issues in ILSpy

Workarounds for AvaloniaEdit behaviour that ILSpy carries in its own code, collected from the pull
requests merged since April 2026 (the Avalonia 12 port and everything after it). Each entry names the
AvaloniaEdit behaviour, what ILSpy does instead, where the workaround lives, and which ILSpy PR
introduced it, so the item can be reported upstream and the workaround deleted once a fix ships.

All findings are against Avalonia.AvaloniaEdit 12.0.0 (released 2026-10-21; the ILSpy pin in
Directory.Packages.props). Upstream repository: https://github.com/AvaloniaUI/AvaloniaEdit.

Candidates to report upstream

1. Scroll increments are fixed pixel constants (10x50 / 10x100)

• AvaloniaEdit behaviour: AvaloniaEdit.Rendering.TextView implements ILogicalScrollable.ScrollSize
  as new Size(10, 50) and PageScrollSize as new Size(10, 100). Avalonia's ScrollViewer derives
  the wheel notch, ScrollBar.SmallChange and ScrollBar.LargeChange from those two values, so a
  Shift+wheel notch scrolls 10 px, a track click 100 px, regardless of font size or viewport.
  WPF AvalonEdit's IScrollInfo scrolled WheelScrollLines * DefaultLineHeight per notch and one
  viewport per page.
• ILSpy workaround: ILSpy/TextView/DecompilerTextArea.cs subclasses TextArea, re-implements
  ILogicalScrollable forwarding everything to the TextView except the two step sizes (wheel lines x
  DefaultLineHeight, page = viewport; macOS 50 px fixed; SystemScrollSettings reads the OS wheel
  setting). DecompilerTextEditor is constructed with it via the protected TextEditor(TextArea) ctor.
• ILSpy PR: #4252 (https://github.com/icsharpcode/ILSpy/pull/4252), fixes #4173 and #4219.
  The PR body contains a ready-made upstream proposal (ScrollSize from WideSpaceWidth /
  DefaultLineHeight, PageScrollSize => _scrollViewport, a TextEditorOptions.WheelScrollLines
  knob) and lists the open design points (horizontal step, arrow-button step, timing, tests).
• Deletable after the fix: DecompilerTextArea and the DecompilerTextEditor ctor argument.
  SystemScrollSettings stays only if upstream adds a settable wheel-lines option that ILSpy feeds.

2. TextView.InvalidateLayer does not repaint the layer visuals

• AvaloniaEdit behaviour: TextView.InvalidateLayer(KnownLayer) only invalidates the TextView's
  measure; the per-layer child controls are never re-rendered. The caret layer therefore repaints
  only on caret blinks (focused editor) or scroll-offset changes. A background renderer registered on
  KnownLayer.Caret in an unfocused editor paints one frame and is never erased, not even when the
  renderer is removed from BackgroundRenderers (removal goes through the same InvalidateLayer).
  The layer control type is internal, so a host cannot target the one layer it needs.
• ILSpy workaround: ILSpy/TextView/CaretHighlightAdorner.cs calls InvalidateVisual() on every
  entry of TextView.Layers on animation start, each frame tick, and on dismissal, and keeps its
  rectangles in document coordinates translated by the live scroll offset per Draw.
• ILSpy PR: #3856 (https://github.com/icsharpcode/ILSpy/pull/3856).
• Suggested upstream fix: InvalidateLayer should also invalidate the visual of the matching
  layer control (and BackgroundRenderers add/remove should trigger it).

3. SelectionMouseHandler skips its own cleanup when the release is already handled

• AvaloniaEdit behaviour: on PointerPressed, SelectionMouseHandler captures the pointer and
  sets its private _mode = Normal. TextArea_MouseMove extends the selection whenever
  _mode == Normal, keyed off the mode rather than the button state. TextArea_MouseLeftButtonUp is
  the only place that resets the mode and releases the capture, and it early-returns when
  e.Handled is already true. A host handler that marks the release handled in the tunnel phase
  leaves the TextArea stuck in selection mode: the next pointer move drags out a selection with no
  button held. There is no public way to reset the mode.
• ILSpy workaround: the reference-click release handler in
  ILSpy/TextView/DecompilerTextView.axaml.cs is registered in the bubble phase with
  handledEventsToo: true, relying on the fact that AvaloniaEdit subscribes from the TextArea
  constructor and therefore runs first.
• ILSpy PR: #3794 (https://github.com/icsharpcode/ILSpy/pull/3794), fixes #3793.
• Suggested upstream fix: reset the mode and release the capture on every left-button release,
  before the e.Handled check; or key TextArea_MouseMove off the pressed button state.

4. SearchPanel is a visual child of the TextArea, not an adorner sibling

• AvaloniaEdit behaviour: SearchPanel.Open() adds the find overlay through TextArea.AddChild,
  so every pointer event on the panel tunnels and bubbles through the TextArea. Host handlers on the
  TextArea that resolve a hit by pointer position (TextView.GetPosition) find the text covered by
  the panel. WPF AvalonEdit hosts the panel in an AdornerLayer that is a sibling of the TextArea.
  SearchPanel.OnPointerPressed marks the press handled, which hides the problem from AvaloniaEdit's
  own handlers but not from handledEventsToo subscribers.
• ILSpy workaround: the reference-click press handler in DecompilerTextView.axaml.cs ignores a
  press whose e.Source is the SearchPanel or one of its visual descendants.
• ILSpy PR: #4250 (https://github.com/icsharpcode/ILSpy/pull/4250), fixes #4245 (an earlier
  attempt was #4264, closed).
• Note: arguably a design decision upstream rather than a bug. Worth reporting as "document that
  the panel lives inside the TextArea" or as a request for an adorner-layer host.

5. TextEditor.ScrollToVerticalOffset / ScrollToHorizontalOffset are no-ops

• AvaloniaEdit behaviour: both methods have empty bodies in 12.0.0. TextEditor.ScrollViewer is
  internal, so a host cannot set the offset through the public API either.
• ILSpy workaround: DecompilerTextView.axaml.cs locates the template ScrollViewer itself
  (editorScrollViewer field, EditorScrollViewer property) and sets Offset directly in
  RestoreOrResetViewState. The headless test helper in #4250 uses the five-argument
  ScrollTo(line, column, VisualYPosition.LineTop, 0, 0) for the same reason.
• ILSpy PR: #3755 (the Avalonia port, https://github.com/icsharpcode/ILSpy/pull/3755); the
  TODO in the code references the upstream fix.
• Upstream status: already fixed. AvaloniaUI/AvaloniaEdit#594 ("Add missing implementation of
  ScrollToHorizontalOffset/ScrollToVerticalOffset") was merged into master on 2026-10-25, after the
  12.0.0 release. Nothing to report; drop the workaround when bumping past 12.0.0. The related
  request to make ScrollViewer public is AvaloniaUI/AvaloniaEdit#603 (open).

6. LineNumberMargin renders with a cached zero font size after a live toggle

• AvaloniaEdit behaviour: when TextEditor.ShowLineNumbers is turned on while the editor is
  live, the freshly inserted LineNumberMargin can render before its cached em size is initialised,
  which throws ArgumentOutOfRangeException from FormattedText (emSize must be greater than
  zero). The editor also inserts the margin at the front of LeftMargins, ahead of any margins the
  host added.
• ILSpy workaround: DecompilerTextEditor.PrepareLineNumberMarginsForRender copies FontFamily /
  FontSize onto every LineNumberMargin and measures it before the first render;
  DecompilerTextView.KeepBookmarkMarginBeforeLineNumbers reorders LeftMargins (margin plus its
  separator Line) so the bookmark gutter stays left of the line numbers.
• ILSpy PR: #4195 (https://github.com/icsharpcode/ILSpy/pull/4195), fixes #4189.
• Upstream status: the crash is AvaloniaUI/AvaloniaEdit#555 ("Crash when toggling
  LineNumberMargin multiple times", open). Add ILSpy's reproduction and the fix idea (initialise the
  em size in OnTextViewChanged/OnAttachedToVisualTree instead of relying on a previous render).
  The margin-order point is a separate, smaller request (insert after host margins, or expose the
  insertion index).

7. TextArea cursor is inherited by inline UI elements

• AvaloniaEdit behaviour: the I-beam is set on the whole TextArea, and Avalonia's Cursor
  property inherits, so every control hosted through a VisualLineElementGenerator
  (InlineObjectElement) shows the I-beam unless it sets its own cursor.
• ILSpy workaround: UIElementGenerator.ConstructElement defaults a freshly realised inline
  control to DecompilerTextView.ArrowCursor when the factory left Cursor unset.
• ILSpy PR: #4170 (https://github.com/icsharpcode/ILSpy/pull/4170), fixes #4148.
• Suggested upstream fix: InlineObjectElement / the inline-object layer could set
  Cursor = Cursor.Default on hosted controls that have none, or the I-beam could be set on the
  TextView text layer only. Related closed upstream report: AvaloniaUI/AvaloniaEdit#585.

8. SearchPanel ignores TextEditor.SearchResultsBrush set after install, and has no theming

• AvaloniaEdit behaviour: the match highlight brush of the find panel is a fixed dark grey unless
  the host calls SearchPanel.SetSearchResultsBrush. TextEditor.SearchResultsBrush is not
  re-forwarded when it changes (for example on a theme-variant switch), and the default has poor
  contrast in dark mode.
• ILSpy workaround: DecompilerTextEditor binds SearchResultsBrushProperty to a theme-variant
  resource (ILSpy.EditorSearchResultsBrush), and DecompilerTextView calls
  SearchPanel.SetSearchResultsBrush(Editor.SearchResultsBrush) at construction, on attach, and on
  every ThemeChanged.
• ILSpy PR: #4167 (https://github.com/icsharpcode/ILSpy/pull/4167), fixes #4159.
• Suggested upstream fix: have SearchPanel observe TextEditor.SearchResultsBrush (or a
  SearchPanel styled property) so one binding suffices, and give the default a theme-aware value.

9. TextView.LinkTextForegroundBrush defaults to pure blue with no theme awareness

• AvaloniaEdit behaviour: VisualLineLinkText paints with TextView.LinkTextForegroundBrush,
  registered with a pure Blue default (1.94:1 contrast on a #1E1E1E canvas). Nothing in
  AvaloniaEdit adapts it to the theme variant.
• ILSpy workaround: an aeRendering|TextView style in App.axaml sets the property from
  ILSpy.LinkForeground, a theme-variant resource.
• ILSpy PR: #4002 (https://github.com/icsharpcode/ILSpy/pull/4002), addresses #3986.
• Suggested upstream fix: a theme-variant-aware default (dynamic resource) for the link brush.

10. RequireControlModifierForHyperlinkClick only reaches the built-in LinkElementGenerator

• AvaloniaEdit behaviour: TextEditorOptions.RequireControlModifierForHyperlinkClick is pushed
  to the built-in generator through IBuiltinElementGenerator.FetchOptions
  (UpdateBuiltinElementGeneratorsFromOptions). A user-added LinkElementGenerator subclass keeps
  whatever the parameterless base ctor set (default true) and never sees the option.
• ILSpy workaround: ILSpy/Commands/ResourceLinkGenerator.cs sets
  RequireControlModifierForClick = false in its ctor in addition to the editor-level option;
  ILSpy.Tests/Commands/HelpCommandTests.cs pins it.
• ILSpy PR: #3755 (commits "Hyperlinks in decompiler view activate on plain click" and
  "ResourceLinkGenerator opts out of Ctrl+Click explicitly").
• Suggested upstream fix: LinkElementGenerator could read the option from the owning
  TextView.Options at ConstructElement time, or the base ctor could take the option.

11. Gutter margins react to every pointer button

• AvaloniaEdit behaviour: LineNumberMargin moves the caret and selects the line, and
  FoldingMargin toggles a fold, on any PointerPressed, not just the left button. WPF AvalonEdit's
  margins handled MouseLeftButtonDown only.
• ILSpy workaround: DecompilerTextView.OnTextAreaPointerPressedForMargins (tunnel) marks every
  non-left press handled when the hit lands inside an AbstractMargin in LeftMargins;
  ILSpy.Tests/Editor/MarginPointerTests.cs pins it.
• ILSpy PR: #4218 (https://github.com/icsharpcode/ILSpy/pull/4218), item 8, following #4042.
• Suggested upstream fix: check PointerUpdateKind.LeftButtonPressed in both margins.

12. Clipboard copy is plain text only

• AvaloniaEdit behaviour: the built-in Copy puts plain text on the clipboard. WPF AvalonEdit also
  wrote an HTML fragment (HtmlClipboard) with the highlighting colours.
• ILSpy workaround: ILSpy/TextView/HtmlClipboardCopy.cs intercepts the copy command and
  builds the HTML fragment itself (syntax plus ILSpy's semantic highlighting);
  ILSpy.Tests/Editor/HtmlClipboardCopyTests.cs covers it.
• ILSpy PR: #3755 (commit "Copy decompiled code as syntax- and semantic-highlighted HTML").
• Note: a feature request rather than a bug. Upstream issue AvaloniaUI/AvaloniaEdit#597
  ("Clipboard issues with AvaloniaEdit 12.0.0", open) may be the place to mention it.

13. HighlightingManager hands out DelayLoadedHighlightingDefinition wrappers

• AvaloniaEdit behaviour: HighlightingManager.GetDefinitionByExtension returns a delay-loaded
  wrapper whose members forward to the real definition that materialises on first touch. The wrapper
  and the inner definition are two objects exposing the same live HighlightingColor instances, and
  HighlightingColor overrides Equals/GetHashCode with content equality, so a host that keys
  state by definition or by color value sees the same colors twice and can theme them twice.
• ILSpy workaround: ThemeManager snapshots original colors per HighlightingColor instance in a
  ConditionalWeakTable (reference identity), making dark-theme conversion idempotent regardless of
  how many definition objects expose the same colors; DoubleDarkConversionTests has a
  characterisation test that fails if AvaloniaEdit changes the equality semantics.
• ILSpy PR: #3989 (https://github.com/icsharpcode/ILSpy/pull/3989).
• Note: more a sharp edge than a bug. Could be reported as a request to expose the materialised
  definition (or to make the wrapper Equals the inner definition) and to document the content
  equality of HighlightingColor.

14. No ConvertTextDocumentToRichText equivalent

• AvaloniaEdit behaviour: RichText, RichTextModel and DocumentHighlighter exist, but WPF
  AvalonEdit's DocumentPrinter.ConvertTextDocumentToRichText was not ported.
• ILSpy workaround: DocumentationRenderer.AddCodeBlock renders <code> blocks in tooltips as
  plain monospace text instead of syntax-highlighted.
• ILSpy PR: #3755 (Avalonia port); still present after the tooltip work in #3772 and #3997.
• Note: feature request.

Smaller API gaps noted in code comments

Not worth individual upstream issues on their own, but could be bundled into one "API surface" issue:

• TextView.LineTransformers exposes only Add/Remove, so a host swapping a colorizer must keep its
  own reference to the live instance (DecompilerTextView.SetColorizer, #3755).
• SimpleHighlightingBrush is the only public concrete HighlightingBrush; theme conversion passes
  any other brush through unmodified (ThemeManager.AdjustForDarkTheme, #3755).
• A theme-variant change (RequestedThemeVariant) does not make AvaloniaEdit redraw; hosts have to
  call TextView.Redraw() themselves (ThemeManager.ThemeChanged, DecompilerTextEditor, #3755).
• Two-key chords (Ctrl+M, Ctrl+M) have no support in the TextArea input-handler chain; ILSpy maps
  folding commands to single-key chords instead (OnEditorKeyDownForZoom, #3755).
• TextEditor.ScrollViewer is internal (see item 5 and AvaloniaUI/AvaloniaEdit#603).
• Subclassing TextEditor or TextArea requires StyleKeyOverride pointing at the base type or the
  template never applies (no ScrollViewer, offsets stay 0). This is Avalonia behaviour, but the
  AvaloniaEdit docs could mention it since the TextEditor(TextArea) ctor invites subclassing
  (DecompilerTextEditor, DecompilerTextArea; #3755, #4252).

Not AvaloniaEdit issues (excluded)

Items that surfaced in the same PR sweep but belong elsewhere:

• #3772: the hover popup was invisible because an OverlayPopupHost resolves its theme through the
  Popup's logical parent (Avalonia OverlayPopups, not AvaloniaEdit).
• #3844: doubled index on macro opcodes was an ILSpy bug in AvaloniaEditTextOutput.WriteReference.
• #3997: NativeMenuItem.Gesture is display-only outside macOS (Avalonia).
• #4039: Mouse4/Mouse5 handling, ShouldTriggerSelection, Dock ActiveDockable re-focus (Avalonia,
  Dock). The only AvaloniaEdit touch point is that an unswallowed X-button press would focus the
  editor or toggle a fold marker, which is item 11 above.
• #4076, #4139, #4138: SharpTreeView scrolling and row ordering (ILSpy's own tree control).
• #3988: editor zoom vs. configured font size (ILSpy settings model).

Method

PR list: gh pr list --state all --search "created:>=2026-04-01" (merged, open and closed), filtered
on AvaloniaEdit-related terms in title and body, then cross-checked against the // ... AvaloniaEdit
comments in ILSpy/ and ILSpy.Tests/ and the commits that introduced them (git blame,
gh api .../commits/<sha>/pulls). Upstream state checked on 2026-10-25 against the AvaloniaEdit
releases and issue list.