`AppLifecycleListener.onExitRequested` never fires on Windows after `pdfrxFlutterInitialize()`

[Markus43]

Summary

On Windows, once pdfrxFlutterInitialize() has run, closing the window with the title-bar X no
longer triggers AppLifecycleListener.onExitRequested, so apps can't run graceful shutdown. It
happens from init alone, before any PDF is rendered, and reproduces on the latest versions.

Environment

pdfrx 2.4.7, pdfrx_engine 0.4.6, Flutter 3.44.7 (stable), Windows 10.

Repro

1. Windows desktop app that registers:

   AppLifecycleListener(onExitRequested: () async {
     debugPrint('FIRED');
     return AppExitResponse.exit;
   });

2. Close with the X → prints FIRED.
3. Add await pdfrxFlutterInitialize(); in main(), run again, close with the X.

Expected: still prints FIRED. Actual: never prints; the app just exits.

Note

After pdfrxFlutterInitialize(), the process owns an extra hidden top-level window
(GDI+ Hook Window Class); removing the init call removes the window and restores
onExitRequested. This appears to defeat the Windows engine's last-window exit check.

[espresso3389]

I investigated this further. The issue is valid and the underlying cause is Flutter's Windows last-window detection interacting with a hidden GDI+ helper window.

The initialization path is:

pdfrxFlutterInitialize()
  -> PdfrxEntryFunctions.init()
  -> FPDF_InitLibrary()
  -> PDFium CFX_GEModule initialization
  -> CWin32Platform::Init()
  -> CGdiplusExt::Load()
  -> LoadLibraryA("GDIPLUS.DLL")
  -> GdiplusStartup(...)
  -> GDI+ creates "GDI+ Hook Window Class"

PDFium initializes GDI+ with the default GdiplusStartupInput, whose SuppressBackgroundThread value is FALSE. This creates the hidden top-level helper window. Flutter's WindowsLifecycleManager::IsLastWindowOfProcess() enumerates all unowned top-level windows in the process, including invisible implementation windows. It therefore sees both the Flutter window and the GDI+ helper window and does not send the cancelable exit request to Dart.

The relevant Flutter implementation is:
https://github.com/flutter/flutter/blob/dcb2cce79439796768e67474f710221f23d797ab/engine/src/flutter/shell/platform/windows/windows_lifecycle_manager.cc

PDFium's GDI+ initialization is here:
https://pdfium.googlesource.com/pdfium/+/4cf91142a765388828b1672b0efb004e1dc3ed75/core/fxge/win32/cgdi_plus_ext.cpp

pdfrx renders with FPDFBitmap_CreateEx() and FPDF_RenderPageBitmap(), not the Windows HDC-based FPDF_RenderPage() path that uses CGdiDisplayDriver and GDI+. Thus pdfrx does not directly need PDFium's GDI+ HDC renderer, but the standard PDFium binary initializes it unconditionally and PDFium exposes no public option to disable it. Maintaining a custom PDFium build only for pdfrx is not desirable.

I could not find an existing Flutter issue for the exact PDFium / GDI+ Hook Window Class case. The closest related issue is flutter/flutter#168335, where using file_selector creates an additional native/helper window and similarly causes the title-bar close action to bypass AppLifecycleListener.onExitRequested on Windows:
flutter/flutter#168335

That Flutter issue was closed without a fix because the reporter could not continue testing. The clean resolution here is likely in Flutter's Windows lifecycle manager: it should not count invisible infrastructure/helper windows as user-facing application windows when deciding whether to send an exit request.