problem with BigPipe and exposed filter and Reset button

Thank you for reporting this, I saw the same issue in other modules too, since Drupal 8.9 the lazyloading was changed a bit. I will try to fix this asap.

The fix was committed to latest dev version. I will create a stable release a bit later, because of this change support of Drupal sites with version lower than 8.8 will be dropped, because this new Interface exists only since 8.8.0.

Just for the reference https://www.drupal.org/node/2966725

The problem persists with dev version? The same error?

It is strange, because the Filter class is now implementing this interface TrustedCallbackInterface. Did you also clean the caches? I am trying now again with dev version

Are you using block view or page? Can you please share the config file with view?

Now I also can reproduce the issue, something changes when there is an exposed filters form with reset button. I will try to investigate further.

Ok, I did some digging, and this is actually a views module problem https://www.drupal.org/project/drupal/issues/2820347#comment-13279928 , because clicking on "Reset" button creates a redirect and causes Drupal\Core\Form\EnforcedResponseException

This TrustedCallbackInterface was not a problem at all, but it is of course good to have it too.

Anonymous users can't use BigPipe, it works only for authenticated users. insert_view is not using placeholders, that is why this problem is not there

Can you please share some more info?

I tried to embed the views page with exposed filter, and without ajax enabled I am redirected to the view page in my case '/admin/content' when I use any filter in exposed form.

If you want to use exposed form in block - it is required to have "Use Ajax" enabled, in other case it will not work.

So, are you using block or page?

Thank you for your time.

Ok, thanks for the info. It is 'embed' display.

I found that when user is authenticated there is op=Reset in the url, but not for anonymous. Checking further

I think I found the solution here. I will try to implement it as soos as possible. The idea is not to render the view with InsertView::build when there is "op" parameter in the url but just render empty markup but have javascript redirect. I hope it will fix the issue.

I have implemented a workaround. Unfortunately, it is not so smooth as normal Reset, because during normal redirect the whole page is not rendered, but with Javascript redirect the page needs some time for rendering and then redirect. At least it is better than nothing.

Please check the latest dev version.

I also made the workaround only for authenticated users, maybe it is also better to check if Bigpipe module is enabled.

Need to think for a better solution, the exposed filter values are stored in the SESSION to, so it needs to be cleaned. I will think more, maybe try to use Ajax for Reset button, so the values in the SESSION are cleaned but the redirect happens on browser side.

In our situation, we are using contextual filter rather than exposed filter in the view/block. The block is not showing in IE when login. Other browser rendered properly.

IE of what version? Are there any "Console" errors? Does it work as a view standalone in IE? What type of view display you have: block, page, embed or other?

Thank you for looking into this.
Using IE11, Console errors : SCRIPT438: Object doesn't support property or method 'forEach', but the console error exists with anonymous user too, so might not the reason the inserted view does not showing.

The view displayed as a block. Standalone block works when place the block on the same page.

span data-big-pipe-placeholder-id="callback=%5CDrupal%5Cinsert_view_adv%5CPlugin%5CFilter%5CInsertView%3A%3Abuild&args%5B0%5D=referenced_view&args%5B1%5D=block_2&args%5B2%5D=&args%5B3%5D=%7B%22id%22%3A%22insert_view_adv%22%2C%22provider%22%3A%22insert_view_adv%22%2C%22status%22%3Atrue%2C%22weight%22%3A-48%2C%22settings%22%3A%7B%22allowed_views%22%3A%7B%22acronyms_tables%3Dblock_1%22%3A%22acronyms_tables%3Dblock_1%22%2C%22acronyms_tables%3Dblock_2%22%3A%22acronyms_tables%3Dblock_2%22%2C%22bulletins_and_technical_news%3Dblock_1%22%3A%22bulletins_and_technical_news ...

Does it also say from which file the error comes in the console? Because the module doesn't use 'forEach' anywhere in the code. BigPipe is very dependendent on javascript, so if there is any error in any JS code on the page BigPipe will not work and will leave the placeholders as they are. That is why the view works also as standalone, because Drupal render placeholders are not used in that case.

Please try to perform the check of JS used on the page and check the compatibility of it with IE 11. Also try to use the polyfill https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global...

Alternatively you can disable BigPipe module (it is enabled by default) and there will be only Small Pipe available that is not using javascript and all the errors will not influence the inserted views.

Thank you very much for your advice, we have cleaned up the error from JS code but did not help with the issue that inserted view not showing. It works when disable bigpipe.

I would like to help more, but for that I need more information, like the view config and all dependent configs. Maybe there is public url, where I can check the view?

Thanks for your quick response and help. Since it any happened when you login with IE, so public url won't help unless your have an account to login. It does happen for any inserted view not specific view configs I guess. You might be able to re-produce the issue on any installation with Bibpipe and adv insert view enabled.

BigPipe is enabled by default on any new Drupal installation. Are you also using dev version or beta-1? There was recently a bug fix in the following issue that is related to contextual arguments here https://www.drupal.org/project/insert_view_adv/issues/3180525 .

The purpose of this module was to use all advantages of BigPipe and SmallPipe to help the parent entity still keep being cacheable.

Hey there, just came across this after:
1. Clean install of latest D9
2. Create new View from scratch, very simple
3. Attempt to embed View using this module, enabled via text filters.

For admin, big set of warning errors:

User error: Drupal\Core\Security\UntrustedCallbackException: Render #lazy_builder callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was \Drupal\insert_view_adv\Plugin\Filter\InsertView::build. See https://www.drupal.org/node/2966725 in /var/www/mrwmg/htdocs/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php:96 Stack trace: #0 /var/www/mrwmg/htdocs/core/lib/Drupal/Core/Render/Renderer.php(781): Drupal\Core\Render\Renderer->doTrustedCallback() #1 /var/www/mrwmg/htdocs/core/lib/Drupal/Core/Render/Renderer.php(355): Drupal\Core\Render\Renderer->doCallback() #2 /var/www/mrwmg/htdocs/core/lib/Drupal/Core/Render/Renderer.php(200): Drupal\Core\Render\Renderer->doRender() #3 /var/www/mrwmg/htdocs/core/lib/Drupal/Core/Render/Renderer.php(156): Drupal\Core\Render\Renderer->render() #4 /var/www/mrwmg/htdocs/core/lib/Drupal/Core/Render/Renderer.php(573): Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() #5 /var/www/mrwmg/htdocs/core/lib/Drupal/Core/Render/Renderer.php(157): Drupal\Core\Render\Renderer->executeInRenderContext() #6 /var/www/mrwmg/htdocs/core/lib/Drupal/Core/Render/Renderer.php(171): Drupal\Core\Render\Renderer->renderPlain() #7 /var/www/mrwmg/htdocs/core/modules/big_pipe/src/Render/BigPipe.php(693): Drupal\Core\Render\Renderer->renderPlaceholder() #8 /var/www/mrwmg/htdocs/core/modules/big_pipe/src/Render/BigPipe.php(547): Drupal\big_pipe\Render\BigPipe->renderPlaceholder() #9 /var/www/mrwmg/htdocs/core/modules/big_pipe/src/Render/BigPipe.php(305): Drupal\big_pipe\Render\BigPipe->sendPlaceholders() #10 /var/www/mrwmg/htdocs/core/modules/big_pipe/src/Render/BigPipeResponse.php(112): Drupal\big_pipe\Render\BigPipe->sendContent() #11 /var/www/mrwmg/htdocs/vendor/symfony/http-foundation/Response.php(381): Drupal\big_pipe\Render\BigPipeResponse->sendContent() #12 /var/www/mrwmg/htdocs/index.php(20): Symfony\Component\HttpFoundation\Response->send() #13 {main} in Drupal\big_pipe\Render\BigPipe->sendPlaceholders() (line 554 of core/modules/big_pipe/src/Render/BigPipe.php).

For anonymous user, page fails entirely with message:

Drupal\Core\Security\UntrustedCallbackException: Render #lazy_builder callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was \Drupal\insert_view_adv\Plugin\Filter\InsertView::build. See https://www.drupal.org/node/2966725 in Drupal\Core\Render\Renderer->doTrustedCallback() (line 96 of core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php)

As noted, BigPipe is enabled by default...and there is no clear way to "disable" or switch to SmallPipe.

Any clues where to go from here?

there is no clear way to "disable"

Bigpipe is a module, you can disable it with admin UI under "extend" menu link.

InsertView class is already implemeting TrustedCallbackInterface (at least in dev version) and build method is among trusted callbacks:

  /**
   * {@inheritdoc}
   */
  public static function trustedCallbacks() {
    return ['build'];
  }

I made a new release https://www.drupal.org/project/insert_view_adv/releases/8.x-1.0-beta2

Unfortunately, there is no clear way to fix this issue. BigPipe and standard "Reset" of views exposed filter are not working together. The workaround was added to beta2, but the page reload (triggered from module's JS) is needed.

I will close it for now. Maybe "Reset" button in views exposed filters will change the behavior in the future and it will be possible to fix this issue.