Package com.iizix.swt

Class BrowserBoot

java.lang.Object
com.iizix.swt.BrowserBoot
public class BrowserBoot extends Object
Boots an SWT Browser through its load + readiness + retry lifecycle.

The SWT Browser widget on the Edge/WebView2 backend (Windows 11) does not finish initializing until its control hierarchy is actually visible on screen. A setUrl (or setText) issued before that moment can be silently dropped: the page never loads, the injected BrowserFunction bridge never becomes live, and any JavaScript→Java readiness callback the site waits for never fires. The browser cell sits blank. Re-issuing the navigation (a manual "Reload") always fixes it, because by then the control is visible.

BrowserBoot centralizes that lifecycle: it owns the readiness handshake, the gated/retrying load, the file: URL pre-validation, and (via the create(org.eclipse.swt.widgets.Composite, org.eclipse.swt.graphics.Color, java.util.function.Consumer<org.eclipse.swt.browser.Browser>, java.util.function.Consumer<org.eclipse.swt.browser.Browser>) factory) creation-failure handling. The site continues to register its own other BrowserFunctions directly on the browser; BrowserBoot does not wrap or manage those.

Two distinct readiness moments are exposed, both as nullable Consumer<Browser>:

  • onBridge — fires when the readiness BrowserFunction is called from the page (JS→Java confirmed). Most sites pass null here.
  • onReady — fires once, on the UI thread, when the browser is REALLY ready, meaning BOTH the readiness BrowserFunction has fired (JS→Java works) AND ProgressListener.completed(org.eclipse.swt.browser.ProgressEvent) has fired (Java→JS into the loaded page works).

CRITICAL: the retry (re-issuing the load) is gated on the readiness BrowserFunction having fired ONLY, never on completed. The original hang was the SWT BrowserFunctions never being injected into the page at all; in that hang completed can still fire (the document loaded) while the bridge is dead, so gating retry on completed would fail to retry the actual hang. The BrowserFunction firing proves injection succeeded, which is the correct retry-stop signal.

All callbacks run on the SWT UI thread (BrowserFunction callbacks and timerExec are UI-thread by SWT contract), so the per-instance state needs no synchronization.

Author:
Christopher Mindus