Opened 7 years ago

Closed 7 years ago

#8439 closed bug (wontfix)

Autocomplete plugin disables custom 'window.onbeforeunload' listener

Reported by: davispw Owned by:
Priority: minor Milestone: 1.10.0
Component: ui.autocomplete Version: 1.8.17
Keywords: Cc:
Blocked by: Blocking:

Description

The fix for jQuery UI bug #7790 introduced a new issue. See ticket:7790#comment:5. If I create my own window.onbeforeunload listener, autocomplete disables it.

$(window).bind('beforeunload', ...) does not support binding multiple listeners. So it's up to autocomplete to check for an existing listener, and delegate to it after doing its own work.

This is a rather insidious issue because upgrading to jQuery UI 1.8.17 will break previously-functional behavior in the user's application. It has the potential to cause data loss because a common use of 'beforeunload' is to warn the user of unsaved changes. Autocomplete binds this listener with no option to disable or restore the previous behavior.

A very hacky workaround is to attempt to reset the custom listener whenever autocomplete is used:

var autocomplete = $.fn.autocomplete;	// original fn
$.fn.autocomplete = function() {	// intercept calls to $().autocomplete()
	var result = autocomplete.apply(this, arguments);	// delegate
	window.onbeforeunload = myCustomBeforeunloadListener;	// reset
	return result;
};

The issue is present as of 1.8.21

Change History (4)

comment:1 Changed 7 years ago by dmethvin

I created a core bug here: http://bugs.jquery.com/ticket/12061

For now I'd say that we should just avoid using $(window).on("beforeunload", fn) in library code given its behavior. But if you need a handler for it, you'll need to address the issues mentioned in the ticket above, including what to do about return values and unbinding if that is needed.

comment:2 Changed 7 years ago by Scott González

Milestone: 1.9.01.10.0

comment:3 Changed 7 years ago by bavanyo

Status: newopen

comment:4 Changed 7 years ago by Scott González

Resolution: wontfix
Status: openclosed

We created a ticket for core to handle this properly, and the fix just landed. I'm closing this as wontfix because we won't be implementing a workaround in jQuery UI, but using jQuery UI with jQuery 1.9+ will solve the issue.

Note: See TracTickets for help on using tickets.