UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce the problem:
var e = document.createElement("link");
e.rel = "preload"; e.as = "fetch"; e.crossorigin = "anonymous"; e.href = "about:blank"; e

What is the expected behavior?
<link rel="preload" as="fetch" crossorigin="anonymous" href="about:blank">

What went wrong?
<link rel="preload" as="fetch" href="about:blank">

Chrome's DOM api silently discards the crossorigin attribute. This results in fetch preloads silently failing, they never work and there is no diagnostic information to explain it.

Did this work before? No 

Does this work in other browsers? No
 Firefox behaves the same way. I believe this is incorrect and it is not specified anywhere in developer guides (like Google Developers) or in the spec, as far as I can tell.

Chrome version: 65.0.3325.181 (Official Build) (64-bit) (cohort: Stable)  Channel: stable
OS Version: 10.0
Flash Version: 

Because preload is ignored, each XHR eats a sequential round-trip to the disk cache process. For the pages I'm dealing with that's 10-60ms per page load.

If you generate a bunch of preload links using a div and innerHTML, the preload functions correctly once you insert the div into the document.head.

P.S. the successfully preloaded XHRs disappear entirely from the network timeline, which kind of makes this hard to debug if you don't know what you're looking for. I'm not convinced that the preloaded assets are actually hitting the in-process memory cache, because the page load times have not improved... but they're not showing up in the timeline and the 'asset was preloaded without being used' warnings are gone, so the preload is working.