Chrome Version: 67.0.3396.79 (Official Build) (64-bit)
OS: Win10

What steps will reproduce the problem?
(1) Launch chrome.exe --trace-startup --trace-startup-duration=20 --trace-startup-file=C:\Users\gab\Desktop\startup_trace.json

(2) Wait 20 seconds
(3) Open chrome://tracing
(4) Load C:\Users\gab\Desktop\startup_trace.json

What is the expected result?
Trace opens

What happens instead?
Parsing JSON fails.

Inspecting the JSON, it's correct except for the "DownloadItemActive" item which has unsanitized Windows paths in its args (with unescaped '\'). Fixing those manually by replacing "\" with "\\" results in valid JSON and a loadable trace.

Other item w/ args with paths seem to escape the '\' fine so I'm not sure why "DownloadItemActive" is special.

e.g. "Profile::CreateProfile" is auto-escaped :
https://cs.chromium.org/chromium/src/chrome/browser/profiles/profile_impl.cc?type=cs&q="TRACE_EVENT1("browser,startup",+"Profile::CreateProfile""&sq=package:chromium&g=0

The problem is that "DownloadItemActive" does its own string conversion in DownloadItemActivatedData and uses an std::string for the path instead of a base::FilePath.

@ https://cs.chromium.org/chromium/src/components/download/internal/common/download_item_impl.cc?type=cs&q=file_name_%5C.c_str%5C(%5C)+file:download_item_impl.cc&sq=package:chromium&g=0

@qinmin who wrote DownloadItemActivatedData ; also, is it normal for this to run early during a regular startup..?

CC primiano FYI if the possibility of getting this wrong influences tracing v2 API design.