[+dbeam]:  Looks like you own crisper.js.

For an even smaller test case:

data:text/html,<a href="" download>Click</a>

This is probably two distinct bugs, one is that the Downloads UI should be handling broken data.url, and the <a> tag should probably be doing some validation with the href attribute.

I'll take this (Mostly because I'm investigating a painful issue this week, and feel like landing a real but tiny fix for something).

And greencardesh, thanks for the high quality bug report!

we're probably doing something like assert(downloadUrl) somewhere and that's blowing up on a falsy string.

i thought that href="" means "the current URL" in this context, but maybe that's historical.

Hrm...Seems if you quit and restart Chrome after downloading the empty URL, the downloads page just spins indefinitely whenever you try to open it.  Seems like that also needs to be fixed.

False alarm...Maybe?  At least after another restart, it's not hanging.  Does seem rather concerning, regardless.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d7f1230e51b779d8f81b140be7cd9db8734d5841

commit d7f1230e51b779d8f81b140be7cd9db8734d5841
Author: dbeam <dbeam@chromium.org>
Date: Thu Aug 11 03:04:09 2016

MD Downloads: ignore empty URLs

R=mmenke@chromium.org
BUG= 635220 

Review-Url: https://codereview.chromium.org/2237713002
Cr-Commit-Position: refs/heads/master@{#411242}

[modify] https://crrev.com/d7f1230e51b779d8f81b140be7cd9db8734d5841/chrome/browser/ui/webui/md_downloads/downloads_list_tracker.cc

So that should fix the immediate issue being reported, however, normal resource requests have some security checks that would block a request with an empty URL, I believe (And we'd also kill the renderer).  Also, blink seems to send a link to "about:blank" for normal <a href=""> on data URLs, but an empty URL for <a href="" download>, which seems rather broken.

Awesome job guys (especially mmenke and gl on that nasty bug you're working on!)

One thing I would like to point out. Is it ok that you can download and execute chrome://resources/* from the downloads page?

Take  Bug 633687  (which is where I originally posted this bug at) 

This isn't a big thing but something irks me about it.

Actually, keeping this open, because of comment 10 (Which I forgot about)

You can also download and link to arbitrary chrome: urls

Example:

<a href="chrome://settings" download="a.html">aaa</a>

1. download it, the download will fail
2. click on show all downloads
3. click on the failed download and it will open chrome://settings.

Marking this as fixed, and filing a new bug for the other issues - https://crbug.com/651084.  Asanka's pointed out that we should probably do a more involved fix that I had intended, and is currently working on a doc.