Can you please share a screenshot (with a short animation if that makes sense?) This always helps a lot when improving the profiler.

Sure, considering there is a dump in the code :

Currently :

After :

If there is a dump, it's very likely that the user wants to see it. It saves one click.

Just added tests.

Can we do this using a special debugging header? If yes, wouldn't it make the implementation simpler?

We can technically do it with special headers. It heavily reduces the amount of added code.
However I see at least three problems :

1. Adding a random header in the collectors looks bad. It adds this logic in the HttpKernel component, thus polluting the component while it's just for us and our web profiler bundle.
2. By using a header, we lose the control of which panels can be accessed directly : any 3rd party collector can force the redirection to its panel if it overrides the header and is "collected" last.
3. Managing the priority of the preferred panel (exception > all) becomes hard because collectors can be processed in any order + their name is dynamic (the collector name === the panel name)

Friendly ping @nicolas-grekas, @ro0NL, @BoShurik, @ismail1432 and @fabpot (since you resolved a discussion), is this going anywhere? I deeply think it's useful and would like to see this in 4.4.

The only thing left to do is to manage the constructor arguments of WebDebugToolbarListener to deprecate not passing a ProfileStack as a 2nd mandatory argument, although I don't understand why it's needed since the class is @final since Symfony 4.3 and according to https://symfony.com/doc/current/contributing/code/bc.html that means it is really final in the next major version (and so the promise does not apply anymore).

I also suggest rewording the PR title (which will appear in generated changelogs) and the commit message to talk about the feature being implemented. The profile stack is not the feature, but an internal implementation detail (proof is that the class is @internal)

@fancyweb thanks for working on this! About the new feature, I like it because it's a nice little DX improvement.

About the technical details, I don't have a strong opinion. I'd like to add less code to implement this ... but this comment shows some compelling arguments against that ... so I'm divided.

I still feel like that's a lot of code for the use case.
Alternative idea: link to ?panel=auto and let that trigger a redirect to the best panel for the corresponding profile. Up to us to implement what "best" means here, eg the dump, or the error page, etc.

@nicolas-grekas Your alternative idea seems very good actually. I will give it a try quickly.

I suggest closing this PR in favor of #33783, which has several advantages IMO:

• it adds logic when someone clicks on the link, rather than adding more work in the listener running for all responses
• the listener runs before the profile is complete (many collectors are collecting things only during kernel.terminate thanks to lateCollect), meaning that its guessing is based on incomplete data. On the other hand, the controller displaying a panel has the full data of the profile.

and btw, putting it in the controller also allows using this guessing in other links (we could make search results use it too).