Okay, okay, calm down, I got the idea
Huh, it's hot here. Nope, was replying to you actually.
I mentioned a useful element. Also just add an option to have back the old filtering log and I'm happy. You don't even have to improve the old filtering log, it was perfect for me and not so cluttered like the beta's filtering log.
This will be addressed in the next beta, we do hear you guys.
It is resizeable and closeable:
Because filtering log is not just for copying request URLs. HTTP headers, content preview, network properties, that is often required to make a decision about the request.
Not just values in the the details pane, thought.
This is not a standard pattern for the grid views like that.
Well, it's standard behavior for that type of content and for your typical log viewer. Maybe you need a different view type then.
This is the easiest solution, but it is absolutely worst if we want to improve the filtering log instead of sticking to the old version. Moreover, if we want to make it better, we especially need your advice, and we will get nothing if you continue using the old one.
That's why there are different tabs and most of the information is on the "network" tab.
We'll check what can be done about it.
HTTP headers information might be crucial sometimes. For instance, it might be useful to see what Cookies are set by the websites. Or when you're dealing with a redirecting (location or refresh headers). Anyways, headers information is located on the network tab, which is not selected by default.
Yeah, we will address it in the first place.
Here is what I suggest:
I must admit, there's not much we can do with this.
Could you please explain? I didn't get it.
This!
That will be not possible due to Javascript/Replace rules and Adguard Assistant is sometimes clicking the ad and not selecting it (at least the last time I used it, was about 1,5 or more years ago).
I am pretty sure the process information might come in handy as request could've arrived from another app/browser.
Details button wouldn't work as others, for instance, prefer to have details pane instead of the old view. So the only way would be to have a checkbox or something like that, and that will mean that we should support two completely different detail views in the filtering log, and that's what I want to avoid.
I realize that we cannot completely replace the dev tools, but we should make it as close as possible.
What do you mean by "path of it"?
It definitely comes in handy for apps, especially Modern apps, where no dev tools are available.
Complete url of the blocked file.
I don't like help from assistants and I'm used to write the rules by hand. Also when I want to add specific block rules for urls which are already blocked by a generic rule that assistant is not working.
That would be the easiest method and the best way to satisfy the users who want more details and minimalists like me who only require the most basic information of a request and want a simple, not cluttered/bloated interface.