This is the same bug that I reported for the 7.x-3.x version of Views module.

Bug description

On a view with AJAX enabled, and an exposed filter that has default values, if the user chooses to leave the filter's values blank, the view respects user's choise only on the first page of the results, whereas if the user moves to next pages, the result comes back different. This sometimes causes empty pages without pager.

Steps to reproduce

  1. Install Drupal 8.0.3-dev
  2. Create the following Article nodes:
  3. nid title
    1   My test article
    2   A beautiful day
    3   My article is super
    4   Master of puppets
    5   Fear of the dark
    6   This article will fail
    7   Awesome article about drupal
  4. Import the view that I paste at the end of that message.
  5. Visit the new view's page: /admin/helper-articles
  6. Type 'article' on exposed filter "title" and DELETE the values from the exposed filter nid (delete both 5 and 10). Click on Apply.

You will see that:

  • You get 3 out of 4 results: nids 3, 6 and 7
  • Exposed filter Title is 'article' as you typed
  • Exposed filter Nid has blank values as you deleted them.

But if you click on the 2nd page on the pager, or the 'next' button', you get an empty view: no results and no pager!
Also you can notice that now the exposed filter 'nid' contains the default values 5 and 10.

More experimenting

To make it more clear, make a small change: Edit the view, and change the pager to 1 item per page.

Visit the view page.
You have 3 results, one on each of the 3 pages.
Now type again 'article' into the title filter, and delete both values on nid. Click Apply.
You get a result of 4 nodes, one on each of the 4 pages.
If you visit page 2 (or 'next'), now you don't get an empty page, because there actually exists a 2nd page, but as you can see, the number of pages is reduced from 4 to 2.

I propose a patch that solves the issue.

The view that was used to test

Please check attached yml file

Comments

efpapado created an issue. See original summary.

efpapado’s picture

Issue summary: View changes
FileSize
8.99 KB
dawehner’s picture

Priority: Major » Normal

@tim.plunkett, @effulgentsia @alexpott @xjm @cottser and @dawehner discussed that and we think that is "just" normal. I'll review it tomorrow,no worries and we fix it.
We just considered that not important enough to be considered as major compared to other major issues.

efpapado’s picture

No disagreements for the priority change :)

As I get it, this line implements a change on the logic. When the GET request is done without ajax, all the parameters get passed on the url, even the non-valued ones. But when the AJAX mechanism ajaxifies the callback, it only passes the valued parameters, discarding the non-valued ones.
I believe this is an inconsistency that should be fixed, and it gets fixed with the patch.

Also please note that the same bug exists on D7 version of Views, I have also opened an issue and proposed a patch there #2646332: AJAX view with exposed filters & default values does not respect user's empty choice (not sure if the maintainers are the same)

efpapado’s picture

Have you thought about this?

dawehner’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -views, -Ajax, -exposed filter, -default value +JavaScript

@efpapado
I agree that we simply should add all query parameters, no matter whether there are values or not. We cannot make any assumptions about other query parameters in the system.

esolitos’s picture

Status: Reviewed & tested by the community » Needs review
+++ b/core/modules/views/js/base.js
@@ -32,7 +32,7 @@
-      if (pair[0] !== 'q' && pair[1]) {
+      if (pair[0] !== 'q') {
         args[decodeURIComponent(pair[0].replace(/\+/g, ' '))] = decodeURIComponent(pair[1].replace(/\+/g, ' '));

Since pair[1] is actually used, shouldn't be there another check to avoid calling the .replace() method on undefined?

droplet’s picture

Looking at patch changes, it may more worth to check out following issue

efpapado’s picture

@esolitos:

No, it is not needed. The array pair is generated by split:
pair = pairs[i].split('=');
So pair[1] is never undefined, it just could be empty string.

efpapado’s picture

Status: Needs review » Reviewed & tested by the community

So I guess RTBC should come back ;)

droplet’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
540 bytes

Patch #0 isn't safe because the pairs[i] can be `undefined`. Therefore both pair[0] & pair[1] are `undefined`

dawehner’s picture

@droplet
Well, this is a bug unrelated with this issue, isn't it?

droplet’s picture

@dawehner,

Yes and No. Because it checked pair[1] before that imply assumed to check pair[0] (in pairs[i].split). If pair[1] is exist, pair[0] must has value also.

efpapado’s picture

@daweher

I think droplet is right.

If query equals to a=b&
then
var pairs = query.split('&') will be an array:
pairs[0] = 'a=b'
and pairs[1] = '' // empty string
So on the iteration, for i=1
pair[0] = ''
and pair[1] = undefined

This means that if (pair[0] != 'q') will be valid, but then pair[1].replace(/\+/g, ' ') will throw error.

His patch is more safe.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Lendude’s picture

Status: Needs review » Needs work

We now have javascript testing available, so this will need tests.

Lendude’s picture

Issue tags: +Needs tests

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.