Intent to remove chrome://net-internals/#tests

[Eric Roman]

I am planning on removing chrome://net-internals/#tests (crbug.com/472313).

Right now I am measuring its usage to confirm that it is not being used. If that pans out, then I would like to remove it for M44.

Let me know if you are an active user of this feature, or otherwise have concerns with this plan.

Cheers.

[Eric Roman]

Forwarding some off-list responses...

On Sat, Apr 4, 2015 at 9:54 AM, MSI Team <msimprovert...@gmail.com> wrote:

Why do you want to remove it?

If the feature is not adding any value, then there is no need to keep it in Chrome.

Philosophy:

For our browser to remain healthy we need to balance our zeal for adding features and experiments with a willingness to remove them if they don't prove their worth.

Keeping an unused or unmaintained feature in Chrome has real costs:

  - Larger binary size (affects initial download, startup, memory usage)

  - Increased code complexity (slows down refactorings, makes it unpleasant to work in the codebase, higher chance of bugs)

  - Increases user fatigue, when constantly experimenting with unpolished or lackluster features

 

Is it a feature bug triagers sometimes ask reporters to use?

That is what I would I would like to know from others on this list :)

I have not asked for users to run #tests in years, and I am not aware of others recommending it either.

When I first wrote #tests it was addressing two common problems at the time:

  - Difference in proxy settings between Chrome/Firefox/Internet Explorer (#tests searches for a Firefox installation and tries using Firefox's proxy settings)

  - Problems with probing for IPv6 support

These situations are not very relevant today. So I would be surprised to find that #tests in its current incarnation is providing value to users or bug triagers.

Cheers.

On Sat, Apr 4, 2015 at 10:48 AM, MSI Team <msimprovert...@gmail.com> wrote:

Maybe you could ask the bug triagers if they ever ask reporters to use it? Thank you.

Yep, that is what I have done (all the network bug triagers are on net-dev list)

[Eric Roman]

The initial data suggests the feature isn't being used, and I haven't heard of anyone using this tool during bug investigation/triage.

I will proceed with removal for M44.

[mic...@lssysqa.com]

why? It was really useful.

[Matt Menke]

net-internals is intended for use in debugging Chrome.  We weren't using that tab to debug Chrome, so it was removed to reduce code complexity, binary size, and maintenance overhead.  There's an effort to move Chrome's network logic into its own process, for instance, and getting rid of the tab means one less thing to post to using an out-of-process network stack.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/62f53c61-cc5c-4690-bdb4-293ae59105ae%40chromium.org.

[PhistucK]

A bit off topic, but I might have missed any announcement regarding removing chrome:net-internals/#events - that is too bad, it was helpful in debugging cases where pages did not load in Chrome. :(

Now the process is tedious with the JSON export and importing into a different page...

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvrwY3KzanH1sJo0Zeh2kz%3DsOvmLwPvmaaJuzNX1p_O%3D4w%40mail.gmail.com.

[Matt Menke]

You can still use about:net-export, and there's an HTTPS URL to do importing - it was done to reduce Chrome's distribution size.  Eventually we may make a tool to bring back live logging via a local HTTP server that monitors the files net-export is writing to or somesuch.

[Ismael Noble]

we mainly use the net-internals page to debug proxy settings in our enterprise env. its removal made me sad.

[Brandon S]

The removal of net-internals really hampers our ability to troubleshoot proxy issues/configurations within enterprise environments. I can't even tell if the PAC file is being read in at this point.

[Eric Roman]

You can still view the effective proxy settings, it just requires more steps (capture a dump, then import it).

See https://bugs.chromium.org/p/chromium/issues/detail?id=892454.

[kp...@cornell.edu]

Hi all, I'm not a contributor to this group but I wanted to chime in here just to say that the latest Chrome update (71.0.3578.98) not only removed net-internals but also broke the proxy auto connect (.pac) functionality. Because net-internals was the only way I could debug problems with the .pac proxy, I'm now completely unable to access internal web pages (mainly jupyter notebooks) and no longer have a way to debug the problem. For me at least this is a critical issue that will force me to switch to another OS unless I can figure out a workaround.

[Eric Roman]

The debugging functionality is still available through chrome://net-export/ + https://netlog-viewer.appspot.com/#import, per the earlier comments.

What is the PAC problem you are referring to?

M71 included a separate policy change to localhost proxying via PAC, is that your problem?

[kp...@cornell.edu]

Oops, apologies. I've managed to get the netlog-viewer app working with net-export dumps, and it works well enough now for my purposes (although netlog-viewer was much more convenient).