Skip to content

[Gtk4] Fix stale/unresponsive fast-view restore buttons and toolbar #3440

Merged
akurtakov merged 1 commit into
eclipse-platform:masterfrom
akurtakov:gtk4-fastview-fix
Jul 16, 2026
Merged

[Gtk4] Fix stale/unresponsive fast-view restore buttons and toolbar #3440
akurtakov merged 1 commit into
eclipse-platform:masterfrom
akurtakov:gtk4-fastview-fix

Conversation

@akurtakov

Copy link
Copy Markdown
Member

On GTK4, widgets have no per-widget GdkWindow, so the native sibling list doubles as both paint order and Composite._getChildren() order. This caused several fast-view (minimize/restore) regressions vs GTK3:

  • Control.destroyWidget() only called swt_fixed_remove() when fixedHandle != 0, silently skipping the native unparent for widgets without a separate wrapper handle. Their Java objects were marked disposed while the native widget stayed alive and rendered, leaving stale toolbar/button remnants behind after a restore.
  • Composite.moveAbove()/moveBelow() raising a Shell-direct child to the front (e.g. a flyout pane) did not actually reorder GTK4 paint order, since the general child-list-preserving behavior needed by other callers took precedence.
  • ToolBar.getItemCount()/_getItems() did not account for a Menu's GtkPopover appearing as a native sibling alongside real ToolItems, causing a ClassCastException and item count/index mismatches when a context menu was attached to a fast-view toolbar.

raise

On GTK4, widgets have no per-widget GdkWindow, so the native sibling
list doubles as both paint order and Composite._getChildren() order.
This caused several fast-view (minimize/restore) regressions vs GTK3:

- Control.destroyWidget() only called swt_fixed_remove() when
  fixedHandle != 0, silently skipping the native unparent for widgets
  without a separate wrapper handle. Their Java objects were marked
  disposed while the native widget stayed alive and rendered, leaving
  stale toolbar/button remnants behind after a restore.
- Composite.moveAbove()/moveBelow() raising a Shell-direct child to
  the front (e.g. a flyout pane) did not actually reorder GTK4 paint
  order, since the general child-list-preserving behavior needed by
  other callers took precedence.
- ToolBar.getItemCount()/_getItems() did not account for a Menu's
  GtkPopover appearing as a native sibling alongside real ToolItems,
  causing a ClassCastException and item count/index mismatches when
  a context menu was attached to a fast-view toolbar.
@github-actions

Copy link
Copy Markdown
Contributor

Test Results (linux)

  101 files   -     2    101 suites   - 2   8m 31s ⏱️ - 6m 30s
4 610 tests ±    0  4 384 ✅ ±    0  226 💤 ± 0  0 ❌ ±0 
2 360 runs   - 1 059  2 324 ✅  - 1 017   36 💤  - 42  0 ❌ ±0 

Results for commit 24e58ab. ± Comparison against base commit 17dedb3.

@akurtakov akurtakov merged commit 80364bc into eclipse-platform:master Jul 16, 2026
26 of 27 checks passed
@akurtakov akurtakov deleted the gtk4-fastview-fix branch July 16, 2026 06:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

1 participant