Not sure if this is related to Blink>Network.

Thanks for the issue...

Tried to reproduce the issue on reported chrome 65.0.3325.181 and latest chrome 70.0.3538.102 Using Windows 7. Attaching screencast for reference.
Steps:
-----
1. Launched chrome 
2. Navigated to given link "https://theconversation.com/a-high-price-for-policy-failure-the-ten-year-story-of-spiralling-electricity-bills-89450"
3. Clicked on ctrl + p and changed to save as pdf 
4. Saved the file on local drive and opened it
As we have observed that the file opens and not observed windows freeze.

@Reprter: Could you please check the attached screen cast and let us know if anything missed from our end and Could you please upgrade to latest chrome stable 	70.0.3538.102, you can download latest chrome builds here:" https://www.chromium.org/getting-involved/dev-channel ". Let us know whether issue still persists.

Thanks.!

Deleted: 854098.mp4 2.0 MB

	854098.mp4 2.0 MB View Download

+folks who may have better understanding of file saving on Windows.

@comment 4:
It seems that the fact that the file is saved to a mapped drive is important, whereas you are saving it locally, thus not hitting the bug.

I really have no idea what can cause this but I can add more Windows experts.
+brucedawson +robliao
This was happening before I moved file dialogs to an OOP process.

TL;DR - we should either do nothing or should consider somehow capping or warning about long path names, but that quickly gets messy.

There is a MAX_PATH value in Windows of 260. This was, presumably, designed so that applications could declare arrays of that size and be confident that they could handle all possible path lengths.

However, this limitation is annoying and therefore an escape valve was added - longer paths can be used if you specify UNC names with a \\?\ prefix. And, starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.

So, this is normal and expected, roughly speaking.

Arguably Adobe reader should be updated so that it can handle long path names, as should every other program including Chrome. Perhaps we should warn the user and offer to truncate the file name, or should automatically truncate the file name, but this is fundamentally a Windows quirk so we could also reasonably decide to do nothing.

https://stackoverflow.com/questions/265769/maximum-filename-length-in-ntfs-windows-xp-and-windows-vista
https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

My initial inclination is that there isn't much we can do. Generally these are things that should be handled by the Common File Dialog, but even at the same time, aliasing and mapped drives can circumvent any sort of checking that can be done.