Loading it as a file ends up trying to load bogus resources, like "file://x.jd.com/mkt/pcwap?&callback=dsp_1504020242543&r=1504020242544".  On windows, looks like these bogus URLs sometimes take really long to fail (20+ seconds).  We're probably stuck in some platform API call.

I've confirmed that "file://hostname/foo" is mapped to \\hostname\foo, and the reason it takes so long is that the Windows method GetFileAttributesEx() takes a long time when looking for non-existent Windows shares.

I am a bit surprised that we let renderers request files on different network shares, but I think if we allow them to do this, there's nothing worth doing about Windows' long timeout when looking for non-existent network shares, so this is expected behavior when requesting these sorts of file URLs.

I defer to the SavePage team on whether the save page logic should be smarter, and the security team on whether we should allow pages on file URLs to request files on different network shares.

Thanks.
How about skipping GetFileAttributesEx() for "\\hostname\foo" as a temporary workaround?

We need to know if it's a file or directory.  Even if we just tried and open it directly, Windows would have the same delay trying to find it on a network share.

yeah, file:// URLs can have hostnames, so this is work as intended..