See https://github.com/eclipse-jdt/eclipse.jdt.ui/issues/528, on Linux we have a problem with opening many Java editor tabs and opening hovers in them. Since each editor keeps an BrowserInformationControl object, an SWT Browser object is kept alive for each editor tab. This in turn means 1 WebKit process per opened Java editor (in which a JavaDoc hover was shown).
We would like to add internal "API" which which BrowserInformationControl can be told to dispose itself, if closed for a longer period of time. Client code that creates a BrowserInformationControl can then invoke this API, to ensure browser based hovers do not live for too long. Our intention is to add a workbench UI preference, that client code can check, to specify after what period a closed browser hover should dispose itself.
See https://github.com/eclipse-jdt/eclipse.jdt.ui/issues/528, on Linux we have a problem with opening many Java editor tabs and opening hovers in them. Since each editor keeps an
BrowserInformationControlobject, an SWTBrowserobject is kept alive for each editor tab. This in turn means 1 WebKit process per opened Java editor (in which a JavaDoc hover was shown).We would like to add internal "API" which which
BrowserInformationControlcan be told to dispose itself, if closed for a longer period of time. Client code that creates aBrowserInformationControlcan then invoke this API, to ensure browser based hovers do not live for too long. Our intention is to add a workbench UI preference, that client code can check, to specify after what period a closed browser hover should dispose itself.