Fixed "blocking io" from FixupURL on UI thread.

FixupURL calls FixupPath who then calls FilePathToFileURL, in which adding
current directory in specific cases (details below) was removed.
That caused DCHECK because getting cwd is protected with AssertIOAlolowed.
Code being removed was reachable from autocomlete, which resulted in
DCHECK. So it was responsible for some "functionallity", but not useful.
I examined, which functionality we will lose: specific paths like "c:",
"с::foo", "c:foo" are recognized as not absolute paths on Windows and cwd
is added. What happens for those URLs: AutocompleteInput::Parse calls
FixupURL, in there SegmentURLInternal recognizes them as having file
scheme on Windows at the same time segmenting to parts is not successful
(url::Parsed is not valid). This functionality is only reachable on
Windows and it is not useful, because those paths with ":" are not valid
relative paths on Windows. For example, autocomlete result like
file:///C:/Users/me/chromium/src/out/Debug/C: (cwd added before C:)
isn't useful.

For other paths of that style cwd-adding code was not called:
  "file://c:", "file://./foo" are segmented successfully
    by SegmentURLInternal, so, no current dirrectory adding here.
  "c:/foo", "c:\foo" - are recognoized as absolute paths, no CWD added
  "./foo.txt", "foo.txt" "foo\foo.txt" - not recognized as having "file"
    scheme, no CWD added.
  ~/directory_or_file URLs - don't need CWD.

Regarding existing functionality working with relative paths:
GetURLsFromCommandLine and ProfileImpl::GetHomePage that can get
relative path(or homepage URL) from command line both use
not FixupURL, FixupRelativeFile function.
FilePathToFileURL is documented in it's comment as taking absolute path
as argument. Also FixupURL (which indirectly calls FilePathToFileURL),
by it's name and description, is not intended to fixup relative file paths.
Not to mention, resolving relative paths to absolute via FixupURL is broken.

Regarding client code that could use functionality being removed
in this fix. Adding cwd was introduced in commit
0135aa172211433181e1cdaf009ff77716e87ff7
https://codereview.chromium.org/137233006
that time FilePathToFileURL was in net_util.cc.
Client code mentioned there is content_shell
Code working with startup URL from there:
 src\content\shell\browser\shell_browser_main_parts.cc(75):
   return net::FilePathToFileURL(base::FilePath(args[0]));
Now this code is not included in project (don't know why).
This particular client code needs CWD adding, it was fixed to use right
function for adding cwd.

R=davidben@chromium.org,pkasting@chromium.org,alekseys@chromium.org,gunsch@chromium.org
BUG=60641
TEST=entering "c:" url will not cause debug version to fail on DCHECK
on Windows, and launching content_shell with argument like foo.html
(this html shouldexist in current diroctory) results in foo.html
contents shown in content_shell and absolute path to foo.html
displayed in addres bar.

Review URL: https://codereview.chromium.org/1068793002

Cr-Commit-Position: refs/heads/master@{#327263}

1 files changed, 3 insertions, 1 deletions

diff --git a/chromecast/browser/service/cast_service_simple.cc b/chromecast/browser/service/cast_service_simple.cc
index 9c7ca6d..d5c1389 100644
--- a/chromecast/browser/service/cast_service_simple.cc
+++ b/chromecast/browser/service/cast_service_simple.cc
@@ -5,6 +5,7 @@
 #include "chromecast/browser/service/cast_service_simple.h"
 
 #include "base/command_line.h"
+#include "base/files/file_util.h"
 #include "chromecast/browser/cast_content_window.h"
 #include "content/public/browser/render_view_host.h"
 #include "content/public/browser/web_contents.h"
@@ -26,7 +27,8 @@ GURL GetStartupURL() {
   if (url.is_valid() && url.has_scheme())
     return url;
 
-  return net::FilePathToFileURL(base::FilePath(args[0]));
+  return net::FilePathToFileURL(
+      base::MakeAbsoluteFilePath(base::FilePath(args[0])));
 }
 
 }  // namespace