Laravel-debugbar: debugbar refreshes on each ajax call

[denjaland]

Hi,

Our codebase has a heartbeat ajax call every X seconds. So we're doing quite some ajax call to be honest. (it is planned to move this to a socket, but we'll need to schedule that for next year probably)

Anyway. On my local machine, I can easily click the "folder icon" in my laravel debugbar, and select which call I would like to see the details for. It works great.
The same code deployed on an AWS instance however, automatically always updates my debugbar view to the latest ajax call which is pretty annoying, because it updates everything every X seconds, and I don't have time to check the queries for a specific call or whatever.

Has anyone experienced this issue and/or found a solution? I have googled and searched the issues on here, but to no avail.

Thanks very much!

[deains]

+1 to this, it's really dumb behaviour. It's impossible to use the debug bar to inspect a request for more than a few seconds because as soon as a new AJAX comes in the bar automatically switches to it. Makes no sense.

Anyway, though I don't know of a way to stop the bar swapping to AJAX calls, what you can do is set capture_ajax to false in the debugbar.php config file, which will stop the debug bar from being populated with AJAX to begin with.

[barryvdh]

+1 to this, it's really dumb behaviour.

That depends on the case. It might be when you're sending 20 requests, but when you load something after a click, you would usually want to inspect the new result.

But you're all welcome to create a PR in https://github.com/maximebf/php-debugbar

[denjaland]

Hi,

What I don't get is that on localhost, it works as expected (no refresh); only on deployed version on a test environment, it switches.

I can see your use case, @barryvdh, but this behavious basically renders the debugbar useless in situations such as mine.

That said, we switched from the heartbeat to a pusher integration, so the issue is less of a problem to us now.

[decadence]

+1 for making this configurable at least

[barryvdh]

As I said, I'm open for a PR to implement this. I'm thinking of a 'pause' button next to the dropdown, to pause ajax switching. Could be just remember clientSide without options in Laravel.

[SimplyCorey]

+1 for pause

[steveheinsch]

A whitelist of ignored URLs/Routes/etc could be helpful for some cases like this, and debugbar just would not capture/report them.

[denjaland]

That's a workaround I wound't like to be honest ;-)

[skyrpex]

A whitelist of ignored URLs/Routes/etc could be helpful for some cases like this, and debugbar just would not capture/report them.

Looks like the cleaniest and easiest solution to this problem.

[denjaland]

Why do you find that clean?
I want to be able to see all requests, and check for issues on any of them. To me it sounds more like a workaround than a fix.

[steveheinsch]

@denjaland It wouldn't be best for ALL situations. I use laravel-caffeine which sends an ajax request every x seconds to keep the session alive. It simply hits an endpoint and returns NOTHING. I'd like to ignore those requests. Also, sometimes when debugging, I don't want it working globally. Just on certain pages/routes. Waiting an additional 1-2 seconds for every page load gets a bit tedious after a bit and having a list of urls/routes to ignore, would come in quite handy. It's not a "workaround" for the scenarios I described...

[denjaland]

Fair enough.
I wiuld consider it another feature request that isn't directly linked to this issue, but I surely get your point and understand how it can definutely help you.

[skyrpex]

I want to be able to see all requests

Oh, I thought otherwise. Maybe a checkbox that tells the debugbar to stop poping up future requests would make more sense. They would still be logged but not activated as soon as they are sent / received.

[barryvdh]

Isn't that what I suggested in https://github.com/barryvdh/laravel-debugbar/issues/670#issuecomment-321741068 :P

[skyrpex]

Isn't that what I suggested in #670 (comment) :P

Oops, that's true 😆

[barryvdh]

I created an except blacklist here: https://github.com/barryvdh/laravel-debugbar/commit/fff9d0723f705a12f11602e0c4f2ed2105d49979

You can specify the urls you want to whitelist, similar to the VerifyCSRF one.

[martinszeltins]

I have the same issue as OP. I wish there was a "Pause" button so it would not switch to the newest Ajax call automatically. It makes it very difficult to debug.

[aliazizi]

I temporary fixed the issue by editing source files

in JavascriptRenderer Put protected $ajaxHandlerAutoShow = false;

[tomandersen]

$ajaxHandlerAutoShow = false in JavascriptRenderer.php works well. I don't know why its not default, as xhr requests are so popular in apps. When I want to look at a single xhr, I want debug bar to stay on that request.

[tomandersen]

So there is a call setOptions($options) in the base maximebf/php-debugbar that takes an option ajax_handler_auto_show - how do I get access to debugbar to set options ? Perhaps in some middleware ??

[tomandersen]

`

namespace App\Http\Middleware;

use Auth;
use Closure;

class DebugBarStuff
{

/**
 * Handle an incoming request.
 *
 * @param  \Illuminate\Http\Request  $request
 * @param  \Closure  $next
 * @return mixed
 */
public function handle($request, Closure $next)
{
    if (!app()->environment('production')) {
        // how to send a message to appear on the debug bar... \Debugbar::info('request...');
        $renderer = \Debugbar::getJavascriptRenderer();
        $renderer->setOptions(['ajax_handler_auto_show' => false]);
    }
    return $next($request);
}

}
`

[tomandersen]

That middleware will shut off the "debugbar refreshes on each ajax call" feature. You need to add a line to your Kernel.php file as well.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this issue is still present on the latest version of this library on supported Laravel versions, please let us know by replying to this issue so we can investigate further.
Thank you for your contribution! Apologies for any delayed response on our side.

[aliazizi]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this issue is still present on the latest version of this library on supported Laravel versions, please let us know by replying to this issue so we can investigate further.
Thank you for your contribution! Apologies for any delayed response on our side.

issue still exist

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this issue is still present on the latest version of this library on supported Laravel versions, please let us know by replying to this issue so we can investigate further.
Thank you for your contribution! Apologies for any delayed response on our side.

[aliazizi]

issue still exist

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this issue is still present on the latest version of this library on supported Laravel versions, please let us know by replying to this issue so we can investigate further.
Thank you for your contribution! Apologies for any delayed response on our side.