Skip to content

Remove general usage of Window unload event #9908

@niloc132

Description

@niloc132

GWT version: GWT 2.11 and below
Browser (with version): Chrome 120 (soft rollout, see chrome link below)
Operating System: any


Description

Browsers are removing the unload event on the browser, as there are replacements available, and the unload event can interfere with newer browser features. See the MDN docs on the unload event for more specifics.

Chrome specifically has a deprecation policy that is warning that this will be removed in the future. For GWT's own usage of unload, this shouldn't matter:

  • Other window events are removed when this event goes off, to avoid memory leaks (only applies to ancient browsers)
  • RootPanel itself adds a close handler to ensure that all widgets are disconnected, to avoid memory leaks (as above, no longer applies)
  • The long-deprecated WindowCloseListener handling also uses this feature.
Steps to reproduce

Use some Window/RootPanel API directly to monitor unload events, or indirectly with window resize/scroll/beforeunload events (such as with PlaceController, DialogBox, RootLayoutPanel). In chrome, you may see a warning/errors that unload events are deprecated for removal.

To fix this, we can probably remove this class of "memory-leak prevention" (which no longer applies in any browser created in the last ten years) - this means RootPanel need not use it, and Window need not initialize close handlers for window resize/scroll events. Likewise, split unload/beforeunload handling to separate initializers.

Window.addCloseHandler should also be deprecated.

This should probably be backported, given Chrome's timeline for this deprecation, unless we get 2.12 to a finished state (and it is barely started) in the next few weeks.

Links to further discussions

https://groups.google.com/g/google-web-toolkit/c/ZVc9yztBurs

Implications around Widget.onUnload and detach event handlers

With the removal of this event from Chrome and the feature from GWT itself, it is even less reliably than before to let a Widget handle its own "onDetach" or to let an Attach(attached=false) event handler observe it.

The browser's pagehide event is one possible option here, but care must be taken:

  • This event is also not reliable
  • This event may be followed by a pageshow event indicating that the page has been displayed again, without reloading. This means that the application is still running, without re-creating DOM elements and widgets, so all widgets must be re-attached to continue handling events. If event.persisted is false, this is not a concern, there will be no subsequent pageshow event, but if it is true, the page might be cached in its current state and later restored.

Developers should consider other approaches to this, such as directly handling bfcache pageshow/pagehide events in the handlers that need to know about the page status changing, rather than behaving as though the DOM elements were disassembled and reassembled.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions