• eugenebng's avatar
    Fixed "blocking io" from FixupURL on UI thread. · b9400dc4
    eugenebng authored
    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
    0135aa17
    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}
    b9400dc4
print_preview_pdf_generated_browsertest.cc 24.4 KB