Remember the last selection disabled, yet persists

I found exactly the same thing. When adding an exposed filter for a fulltext search I had entered some nonsense text while testing, then later I unchecked 'Remember the last selection'. But every time I returned to the page it was back again, and nothing I did in the settings would get rid of this nonsense text from appearing the search field. If I searched for something else it wouldn't wipe it out. Even after deleting the filter and adding it again it still persisted.

Later on I re-enabled 'Remember the last selection' and then searched for a blank string, then disabled 'Remember the last selection' again and this has the desired behaviour of the search form being blank when I first visit it, but I feel like it was a fudge and that this is being stored in the database somewhere due to this bug.

Perhaps someone who knows how the selection is remembered per user could shed some light. Changing the name of the field fixed it but changing it back made the remembered string come back.

Perhaps someone who knows how the selection is remembered per user could shed some light. Changing the name of the field fixed it but changing it back made the remembered string come back.

it's stored in the session, so you could clear that and then everything would be fine.

Another way could be to actually check in the specific code not only that something is in the session,
check for that "remember last selection" checkbox.

Ran into this issue today.

Very easy to recreate:

1. Create a view with an exposed filter (eg title) and tick the 'remember' checkbox.
2. Go to the view page and use the exposed filter to find something.
3. Refresh the page and the value will still be in the input box (as it should be).
4. Go back to the view settings and un-tick the 'remember' checkbox.
5. Navigate back to the view page and the exposed filter is still remembering! In fact whatever you search for from now on, when you refresh the page it'll remember the term you entered way back when 'remember' was ticked.

This is because $view->get_exposed_input() checks for the existence of the session variable but doesn't check to see if the filter still allows remember. Because the session variables don't get cleared, the session variables from before remain.

Clearing the session variables could work however it might be destructive (what if I accidentally ticked the 'remember' checkbox, realised I'd made a terrible mistake, and all my users remember options were cleared) so this patch addresses the issue simply by checking whether each filter in the current display has the remember option enabled.

Let me know what steps I can do to get this into the D8 version (if it suffers from the same issue).

Changed version number to dev.

Re-queued for testing.

The patch for me works fine and solves the issue.

Before the patch I had to disable 'exposed' for the fields that I wanted to clear the 'remember' value, but keep them and add them again second time with 'exposed' on.

Yes, this indeed solves the mysterious persistence of exposed filter values. For me the issue emerged in a geofield proximity field.

Patch from #6 still applies.

I just ran into this issue using views 7.x-3.13 ... I'm curious to know why #6 never got committed? I assume it just fell out of sight and out of mind of the maintainers...

I'm upgrading this to major because of the troubleshooting time it took me to figure it out, and the fact that I cannot figure out how to delete the remembered value from the mysql DB, which means a contrib module coded view is now broken....

I think the problem might actually be this bug: https://www.drupal.org/node/1349080 instead. Linking here in case anyone else gets confused in troubleshooting as I did.

+++ b/includes/view.inc
@@ -431,7 +431,11 @@ class view extends views_db_object {
+        foreach ($this->filter as $key => $filter) {
+          if (!empty($filter->options['expose']['remember'])) {
+            $this->exposed_input = $_SESSION['views'][$this->name][$display_id];
+          }
+        }

MH, I'm not entirely convinced by this solution ... we still copy all the values from $_SESSION, ignoring different configuration on different filters.

@dawehner -

Do you have a different / better idea about how to solve this, then?

Undoing my promotion of the bug from normal to major.

As per the comment #12, I have modified the patch with one extra condition.
Unset session if parameter exist in case remember selection is not enabled or disabled.

Re-queued for testing.

The 2 year old patch in #16 to view.inc does not apply to the latest views 7.x-3.x-dev and if still relevant needs to be rerolled.

Checking patch includes/view.inc...
error: while searching for:
      $display_id = ($this->display_handler->is_defaulted('filters')) ? 'default' : $this->current_display;

      if (empty($this->exposed_input) && !empty($_SESSION['views'][$this->name][$display_id])) {
        $this->exposed_input = $_SESSION['views'][$this->name][$display_id];
      }
    }

error: patch failed: includes/view.inc:431
error: includes/view.inc: patch does not apply

Re-rolled patch from #16

Applies cleanly to current 3.x-dev & 3.23 (same code at the moment) & fixes the issue.