You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have some very large non-singleton popups in our application, and when we upgraded GWT-P and pulled in this code, the application started leaking a ton of memory and slowing down. Window lives forever, and popups never get GC'd.
Overloading repositionOnWindowResize to return false prevents the addition of the resize handler, which works us around the issue.
The text was updated successfully, but these errors were encountered:
We encountered a fairly large memory leak in the latest
version of GWT-P. All GWT-P popups have a resize handler
attached to them, but this handler lives at window scope
and never lets go. Therefore, every popup is completely
leaked when closed.
However, luckily, the method in GWT-P that sets up this
handler has a hook/template method for disabling the addition
of the handler:
if (repositionOnWindowResize()) {
Window.addResizeHandler(new ResizeHandler() ...
We simply overload repositionOnWindowResize() to always
return false and the leak is worked around.
See: ArcBees/GWTP#823
Change-Id: I4e6d4da68e3f50f5863f4e33e62581b97e36dd2d
Signed-off-by: Greg Sheremeta <[email protected]>
Hi,
GWTP/gwtp-core/gwtp-mvp-client/src/main/java/com/gwtplatform/mvp/client/PopupViewImpl.java
Line 70 in 8620f6b
We have some very large non-singleton popups in our application, and when we upgraded GWT-P and pulled in this code, the application started leaking a ton of memory and slowing down. Window lives forever, and popups never get GC'd.
Overloading repositionOnWindowResize to return false prevents the addition of the resize handler, which works us around the issue.
The text was updated successfully, but these errors were encountered: