Tested the same on mac 10.11.5 chrome version 52.0.2743.116 - Observed the command line detail in the browser matched the values entered

Please find the screenshot

Could you please try the same on a new profile and update the thread. If issue still exists please provide the os details

Thanks. I can verify that it works correctly on my personal mac and windows pc. I believe this may be related to an incompatibility with Websense (TRITON AP_ENDPOINT) v8.2.

When I updated to chrome 52.0.2743.116 chrome barely started up. An upgrade to our corporate Websense (TRITON AP_ENDPOINT) to version 8.2 allows chrome to be usable but i can not start it with a proxy switch (any proxy switch). 

Launching chrome with a proxy switch worked previously with chrome 51 and an older version of Websense.

I am testing on Windows 7 Pro SP1.

I am unable to get a chrome_debug.log file for this issue from my pc. Its almost as though an exception occurs during command line processing that forces chrome to use its default launch parameters. This includes binary apparently. I tried a different chrome binary but the default ended up being launched with no parameters.

Is there any logging from the command line processing i can enable? Or any other logging that can help? 

Try killing all running instance of Chrome first.

One possibility is that you are already running an instance of chrome on the system for the indicated profile directory. Launching chrome.exe "de-duplicates" per profile, so that would have the effect of just switching to the already running chrome (which may have been launched with different flags).

As for why --no-proxy-server seems to make a difference, dunno. Have you tried moving that flag to a different position in the command line (say at the very beginning). One thing I notice is that you are putting that right after the --user-data-dir flag. The escaping looks correct, but if something did go wrong with the escaping maybe adding that flag at the end is changing the profile directory that is used?

Not sure, just some ideas.

Another thing to try is using Process Explorer and inspecting what the actual command line used to launch the .exe was. This will conclusively tell you if it is a parsing problem in Chrome (not interpreting its command line correctly), or a problem with the shell invocation (and the exe you are interacting with was actually one launched with a different command line than expected).

nna.e.ene:  Have you tried eroman's suggestions?  If we don't hear back from you, we'll just close this issue.

Thank you for providing more feedback. Adding requester "tkonchada@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Still waiting on feedback.

Archiving this issue since no feedback is received for more than two weeks. Feel free to file a new bug if you still have the issue.