Thanks for the feedback Justo!

I completely agree with your assessment that the number of choices for proxy is overwhelming, confusing, and inconsistent.

There are even more cases not mentioned in the first comment, such as Safe Browsing requests, requests issued as part of certificate verification (AIA, OCSP, CRL), WebRTC, 64-bit vs 32-bit versions of Chrome, per-profile proxy settings, per-network interface proxy settings, Command-line overrides, policy overrides.

What is less clear is the resolutions to these problems, as there are unfortunately technical or policy reasons for most of these:

  * GoogleUpdate.exe is responsible for updating chrome.exe, and uses a completely separate networking implementation by design so bugs in Chrome code wouldn't prevent Chrome from being updated. Even if we wanted to make it use Chrome's proxy settings, it is unclear what that would mean since proxy settings may vary between profiles and users, and yet the update mechanism may be across all users. So GoogleUpdate.exe probably makes sense to use separate settings (in this case the winhttp/wininet ones).

  * Google Translate not using Chrome's proxy settings sounds like a bug. Can you provide more information on how to reproduce that? I am not familiar with the feature, but it may be a situation similar to Safe Browsing where the requests issued are not associated with a particular Profile, and hence use the global proxy settings rather than the per-profile proxy settings.

  * WinInet vs WinHTTP is a historic implementation issue on Windows. Since Windows 10 it is clear taht WinInet is the preferred option, as WinHTTP is poorly supported. This is something that Chrome needs to fix: Issue 118385

thank you for your reply, Eroman!

First of all, as you said, the nine-grid maze brought by chrome and win10 were caused by the complexity of history and reality.

As you said, there are quite a few complex technical development trends, but I'm sorry I didn't specify my using environment, but which you want doesn't seem to be more critical to explain this question, and it was spead to multiple chrome versions and windows systems, and then I will give you more detailed configuration of the environment that you want.

As you said, proxy is indeed used as a secure browsing application. In fact, it is largely used to circumvent online censorship. The Chinese people chose socks5h (an upgraded version of socks5) proxy against the censorship (sock4a too, but has been replaced by socks5, not commonly used) This protocol is more versatile and convenient than the http-proxy protocol, not only for web browsing but also in use of the TCP flow, which have been used with port-based and PAC-based approach to Internet access.

Compared to VPN as a global proxy, switching between censored and non-censored websites is really too cumbersome to use. Though, if we use VPN, the nine-grid maze we were discussing now does not exist anymore: the VPN intercepts all network traffic.

The current strategy of chrome approaching to winInet and winhttp is exactly the story replay of another cumbersome VPN.

For example, to play chrome browser to open both www.bing.com and www.google.com in two tabs. The former is a non-censored website in China and not been blocked. the latter's IP, domain(DNS poisoning) and TLS certificates have all been intercepted and cannot be accessed directly.

None of VPN, winInet or winhttp could deal with this condition well, as they all act on chrome browser, not every independent tab. An other similar rigid demand is how to do if you want chrome go via proxy but open other programs not via proxy in ONE Windows(or ...) system.

So, we gave up winInet, winhttp and VPN, we chose socks5h(remote DNS resolve) + PAC. finally, I give my opinion with so much words to "vote buying" chrome development for PAC proxy(socks5h) rather than three others :p
PAC proxy mode is minimizing the impact of other software or other tabs, the maximize freedom, the minimize trouble.

  * As the maze table test showing, we can give up the discussion of GoogleUpdate.exe, it is rarely to run and it lives a good life with winInet and winHttp protocol... but you might not konw, in China, large number (gangster) Internet companies copy the source code of chromium to make their own issues browser, the most important reason is that chrome's(of Google) update check and (update) package download sites have all been DNS poisoned and IP blocked...

  * For surfing webpage, PAC+socks5 can deal with very well in China. eventhough Yankee do no know that...

  * As for build-in google translate, in my computer, it is still chaos, I tried to close winInet and PAC plug-in, only activate winhttp, uncertainly sometimes works, sometimes not. 

  * As what mentioned before, winInet is a system-wide proxy, best-hated ones, but winInet is the one of only two ways that can make G translate work, another way is setup a connection redirector proxy software like https://www.proxifier.com/ to catch and en-proxy it.

  Suffering so many mishaps with DNS poison, IP block, MS and Google complex ...

  And the above all, I just wish chrome browser could add PAC proxy support to build-in google translate, it just means several  javascript clauses, although market value of China ,Iran and North Korea were not a thing.

suggestion at last: change the mouse context menu "T" in webpage of chrome to toggle key, first "Translate to..." and then "Show original page..."

Reference: https://blogs.msdn.microsoft.com/ieinternals/2012/09/26/braindump-dns/

Just to clarify - by socks5h you just mean SOCKS5 using proxy-side hostname resolution? (in other words, the way that Chrome's interprets any socks5:// or SOCKS5 proxy from PAC).

The main actionable issue in this thread is Google Translate not working. I will narrow the scope of this bug to that particular item.

As per above discussion this issue seems to be out of TE scope of triaging. Could someone from Internals>Network>Proxy or UI>Browser>Language>Translate team please have a look at this issue. Hence adding TE-NeedsTriageHelp label.

Thanks!

I will defer to Translate folks for more information on the networking context it uses.

It looks to me like translate just uses the SystemURLRequestContext, so this may not be a translate issue, but a SystemURLRequestContex issue.

https://cs.chromium.org/chromium/src/chrome/browser/translate/translate_service.cc?sq=package:chromium&l=54

If the intent is to use SystemURLRequestContext, then we can't fix this bug (which is that translate is not using the per-profile proxy settings).

I don't know anything about the translate feature, but perhaps it could/should be scoping its networking to the profile.

sorry for the late reply.

First, sure there are issues with chrome's built-in traslate for network proxy access. It is speculated that it is not certain to use winInet proxy, but rather several internal judgments. For example, suppose I can only access google translate service via proxy. When I first run chrome, then modify winInet proxy, chrome traslate does not work. Then, I start the proxifier (this is a global proxy programe, capture and redirect network packages to proxy) and intercept traffic to the proxy, after that chrome built-in traslate can work. Then I close the proxifier and the chrome traslate can continue to work well!
I estimate that chrome's built-in translate uses multiple judgments to determine network proxy selection.

Second, I'm not very clear about the working mechanism of chrome, but if the built-in translate can use the same proxy mechanism as web surfing access, all problems are solved. Above all, whether or how to select socks5h or http proxy is up to the user.

The reason I wrote so much is that chrome can unify 9 or more access methods and make it easier for users to use -- that is, I can use ONE way to handle Internet proxy access, upgrade chrome, and built-in translate. And I recommend pac-socks5 method.

Anthony can you take a look for the translate side of things? Some potentially helpful context for how Translate handles proxies in #c50 by toyoshim@ in crbug.com/118171.

Ladies and gentlemen, here add some correction to what I have discovered: I have found that the built-in google translate could use pac proxy, but it requires an activation process first.

First step, I used the proxifier program to intercept all traffic of chrome browser to proxy. Obviously, the built-in google translate will only be able to access the internet through the proxy. But after I closed the proxifier, I found that the built-in Google translate actually chose to use the built-in pac proxy controller, such as SwithyOmega to access the proxy server. 

In other words: First, the built-in Google translate has the ability to access the proxy through the pac controller. Second, it requires an activation? As above … Chrome is really a complex Leviathan... including your development level, LOL

Hi, guys, how is going?
For the google chrome built-in translation issues, currently I am using chrome 69.0.3497.100 bit64 in win10:

1, chrome built-in translation still can't "automatically select" socks5 or http proxy. On the contrary, it is obvious chrome has this ability. The above email I found a way to confirm this problem, using proxifier (this is a standalone software https://www.proxifier.com/) to intercept traffic to the proxy globally in win10 environment, this time chrome built-in translation goes via the proxy of proxifier.

But after I turned off the proxifier, the chrome translation could shift to "other" pac proxy (set by chrome plugin - SwitchyOmega) immediately.

This shows that chrome has built a route-proxy agent selection sequence already, and for user selection, this is not transparent and can't be set, and the user logic is very confusing.

2, the current web page right-click menu "T" can translate the page, but hope that there is also a shortcut key by which you can exit the translation mode back to original page, or display the original text in paragraph, but not all page.

If it can appear as a suspension layer as a contrast, it is convenient for users to compare or even submit changes to Google, it is better.

3, or more advanced, you should join Google AI, and let users help you improve the translation. So far, quite a lot of mentally handicapped translations have been found. For example, in google translation, almost all places where Chinese "著" should appear are mistakenly translated into "着". "著名" should be "famous" meaning, but "着名" is nothing in Chinese. But in the google chrome built-in translation, there is no such entry to help Google improve.

Or is your translation completely equating two words bwteen "著" and "着"? Look at the screenshot

Thanks, hope to see these new improvements in chrome 70.

Deleted: Snipaste_2018-10-10_17-12-48.png 1.6 MB

	Snipaste_2018-10-10_17-12-48.png 1.6 MB View Download