Ticket #7790 (closed bug: fixed)

Opened 3 years ago

Last modified 2 years ago

Autocomplete-enabled text input does not keep value when using back button in browser

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

Description

When using ui.autocomplete in a form, the value of the text box gets submitted correctly. However, if instead of submitting the form, you browse to a different page (often accidentally) and then press the Back button in the browser, the text box will have reset to the value it had when it was first rendered.

Standard "text" input fields remember their value and it would be nice if autocomplete-enabled "text" input fields could too.

As it is, when I am editing my address form and navigate away and press the back button, all the fields remain just as I left them except for my State field (which is using autocomplete), which reverts back to the value it was populated with (from the database) when the page was rendered by the server.

Example: Go to  http://jqueryui.com/demos/autocomplete/#default, select Java from the list, click the Download link at the top, and then the Back button in your browser.

Expected: The #tags field to still have a value ($('#tags').val()) of "Java". Instead, it has a value of "".

Another manifestation of the same bug (I believe) is that if you do Duplicate tab in Chrome after changing the value, that new value is lost for the autocomplete text input but not for the normal text inputs on the page.

Tested in: Chromium, Chrome 14.0.835.202, Firefox 7.0.1.

Change History

comment:1 Changed 3 years ago by TylerRick

After further investigation, I think I've discovered the root of the problem:

It appears that disabling the browser's native autocomplete functionality for an input also disables its ability to remember what its value was when you return to the page via the back button. This appears to be true in both Chrome and Firefox. Here's a simple test (runnable at  http://jsfiddle.net/TylerRick/aaRSk/):

<input autocomplete="off" type="text" name="test" value="change me"/>

To reproduce behavior: Change the value of the input, then click the jsFiddle logo in the top-left corner, and press Back. It will have reverted to its starting value of "change me".

This is the line in jquery-ui-1.8.16/ui/jquery.ui.autocomplete.js that disable's the browser's native autocomplete functionality:

      .attr( "autocomplete", "off" )

When I remove that line and try leaving the page and pressing Back, it does in fact keep the value as I left it just before leaving the page. And the jQuery UI Autocomplete plugin is still fully functional.

However, the browser's native autocomplete drop-down list drops down over top of the plugin's drop-down list, which is probably the reason the author of this plugin disabled native autocomplete.

The native autocomplete can apparently be dismissed with Esc without dismissing the plugin's list (a second press of Esc will dismiss that list too), but leaving native autocomplete on is probably still too much of a usability problem to recommend removing this line.

Having said that, does anyone know of any other solutions to this problem?

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

  • Status changed from new to closed
  • Resolution set to fixed

Autocomplete: Re-enable native autocomplete whent he page is unloaded. Fixes #7790 - Autocomplete-enabled text input does not keep value when using back button in browser.

Changeset: 81b2ef4a6088cb99863c2d318947355a58019362

comment:3 Changed 3 years ago by Scott González

Autocomplete: Re-enable native autocomplete whent he page is unloaded. Fixes #7790 - Autocomplete-enabled text input does not keep value when using back button in browser.

Changeset: b41873ba0dd8f84ec282f77d029c7dc0ee99b873

comment:4 Changed 3 years ago by scott.gonzalez

  • Milestone changed from 1.9 to 1.8.17

comment:5 follow-up: ↓ 10 Changed 2 years ago by russellg99

I believe this bug needs to be re-opened. The fix added for this in 1.8.17 causes a problem when the page sets a "window.onbeforeunload" handler, because the fix overwrites the handler with a new function and the original function is lost.

In the first changeset above (81b2...), the following code was added to autocomplete.js, in the _create() function:

// turning off autocomplete prevents the browser from remembering the
// value when navigating through history, so we re-enable autocomplete
// if the page is unloaded before the widget is destroyed. #7790
this._bind( doc.defaultView, {
  beforeunload: function() {
    this.element.removeAttr( "autocomplete" );
  }
});

The code has since been changed slightly in 1.8.18, and in today's version of the code currently in github, but the problem still happens in those versions as well.

An example showing the problem can be seen here:  http://jsfiddle.net/EuTgH/

comment:6 follow-up: ↓ 7 Changed 2 years ago by scott.gonzalez

So don't do that. Bind using jQuery, like the autocomplete plugin does.

comment:7 in reply to: ↑ 6 Changed 2 years ago by russellg99

Replying to scott.gonzalez:

So don't do that. Bind using jQuery, like the autocomplete plugin does.

That's a good workaround, thanks. However, I don't think overwriting an unsuspecting user's onbeforeunload handler is a good solution. It took me quite a while just to figure out what was causing the problem, and even if this restriction was documented somewhere, I wouldn't have known it was the autocomplete code causing it. Couldn't the original function be saved and appended to the new one being added?

comment:9 Changed 2 years ago by jjdunn

I also object to the fix for this bug. I've spent many hours trying to find the problem. My app binds an anonymous function to the onbeforeunload event, and when I refresh part of the page that has a jQueryUI widget, the ajax response (which includes the jQuery UI autocompleter) overwrites my already-bound handler. So the solution proposed in comment:6 is not acceptable to me.

I'm going to remove this patch from my copy of jQuery UI.

Strongly recommend finding another solution; this one is exceptionally unfriendly.

comment:10 in reply to: ↑ 5 Changed 2 years ago by davispw

Replying to russellg99:

I believe this bug needs to be re-opened. The fix added for this in 1.8.17 causes a problem when the page sets a "window.onbeforeunload" handler, because the fix overwrites the handler with a new function and the original function is lost.

I filed ticket:8439 to track this new issue.

Note: See TracTickets for help on using tickets.