Tracking issue for 8 pre-existing bugs in the legacy GTK3 implementation files (now named *_gtk3.go after #5463). CodeRabbit's review of #5463 surfaced these — the lines were marked as changed by the file rename, but the bugs themselves predate the default-flip.

These were inherited verbatim from the pre-rename *_linux.go files (the GTK3 implementation that was the default before #5463). The mechanical rename in #5463 did not introduce them; it merely made CodeRabbit notice them. All affect the legacy -tags gtk3 build path only.

Findings

v3/pkg/application/application_linux_gtk3.go

1. Lines 156-168 — Early return nil skips startup handlers. After emitting ApplicationOpenedWithFile, the function returns immediately, skipping registration of the ApplicationStartup handler and the setupCommonEvents() / monitorThemeChanges() / monitorPowerEvents() calls. Either remove the early return so normal startup flow continues after the file-open event, or add a comment explaining why the abort is intentional.
2. Lines 249-260 — Out-of-bounds risk in getTheme. body[2] is read without ensuring len(body) >= 3. Also missing type-assert safety on body[2] → dbus.Variant and its Value() → string. Need len(body) >= 3 guard plus safe .(dbus.Variant) and .(string) assertions returning \"\", false on failure.

v3/pkg/application/linux_cgo_gtk3.go

3. Lines 569-573 — appName frees GLib-owned memory. C.g_get_application_name() returns a pointer to internal GLib storage; the defer C.free(unsafe.Pointer(name)) must be removed or the heap is corrupted. C.GoString already copies into Go memory.
4. Lines 697-701 — clipboardGet leaks gchar* from gtk_clipboard_wait_for_text. The returned C string must be freed with C.g_free after the C.GoString copy. Check for nil before convert; free after.
5. Lines 460-472 — Calloc.String / Calloc.Free use value receivers — append(c.pool, ...) modifies a copy; the pool never grows on the original. Change both methods to pointer receivers (*Calloc). Also clear the pool after free.
6. Lines 1838-1841 — zoomOut uses negative multiplier. ZoomInFactor := -1.10 yields a negative zoom that setZoom clamps to 1.0. Use the reciprocal: zoomOutFactor := 1.0/ZoomInFactor.
7. Lines 1095-1108 — execJS leaks a C.CString(\"\"). The empty-string allocation passed to webkit_web_view_evaluate_javascript is never freed. Either preallocate a shared empty C string symbol or explicitly free after the call.

v3/pkg/application/menuitem_linux_gtk3.go

8. Lines 79-85 — setHidden passes the hidden flag directly to widgetSetVisible — inverting behavior. Negate: widgetSetVisible(l.native, !hidden).
9. Lines 87-99 — setAccelerator has a development fmt.Println(\"setAccelerator\", accelerator) that should be removed (or routed through a proper logger guarded by a debug flag).

v3/pkg/application/menu_linux.go (and its _gtk3.go twin) — separately tracked

10. (Tracked as [v3] Menu.Update() is a no-op after first call due to processed guard in processMenu (Linux) #5464 already): processMenu() has a one-way processed guard that makes Menu.Update() a no-op after the first call. Affects both stacks.

Origin

Pre-existing in master before #5463. The _gtk3.go files were renamed in-place from the pre-flip _linux.go files; the bugs predate the rename. Some of them likely predate #4958 too (the original GTK4 introduction PR).

Why not in #5463

PR #5463 is a mechanical default-flip — file renames, build constraint inversions, label updates. Bundling behavior fixes into the rename diff would have made the diff harder to review (and CodeRabbit's findings here prove the rename diff alone is already large enough).

References

• Origin PR: feat(linux): flip GTK4 + WebKitGTK 6.0 to the default build (#5459) #5463 (the GTK4-default flip — the lines became visible to CodeRabbit because they were touched by the rename)
• CodeRabbit's full review: feat(linux): flip GTK4 + WebKitGTK 6.0 to the default build (#5459) #5463 (review)
• Related: [v3] Menu.Update() is a no-op after first call due to processed guard in processMenu (Linux) #5464 (the menu processed guard, which affects both stacks)