It looks like the problem is consistently that unhandledrejection works when it's in the .html file and fails when it's in a separate script file.

A JSFiddle sample (https://jsfiddle.net/6n3pvpx1/), Chrome's Promise Rejection Events Sample (https://googlechrome.github.io/samples/promise-rejection-events/), and my "working" test case all put the event handler within the .html, and all work.  (My React application also works when I put the event handler within the index.html.)

My "notworking" test case and my React application put it in a separate file, and it fails.  I've tried different variations of putting it in a separate file - a DOMContentLoaded handler, a button click handler, a timeout - and all fail.

Tested this issue on Windows-10 using chrome latest stable #54.0.2840.59 by following steps mentioned below.

1. Downloaded file unhandledrejecton.zip
2. Opened index.html file from not working folder
3. Observed a pop up saying "This page says About to fail"
4. Opened index.html file from working folder
5. Observed two pop ups saying "This page says About to fail" and "This page says oh no!"

While testing the same issue on chrome previous version of chrome #35.0.1849.0 & #40.0.2172.0. Observed only one alert saying "About to fail" from both the folders working and not working. Could you please let us is this is the expected behavior of the issue? 

Displaying "Oh no!" is the desired behavior. ("unhandledrejection" is commonly used for error handling; the two test cases intentionally trigger a failure then see if they can correctly see it. A real application would have do something more productive than saying, "Oh no!")

According to https://www.chromestatus.com/feature/4805872211460096, unhandledrejection was added in Chrome 49, so I would not expect Chrome 35 or 40 to work.

As per comment #4 I have rechecked this issue on Windows-10 using chrome M49 #49.0.2623.112 and observed the same behavior as seen on latest stable M54 #54.0.2840.59. 

So considering this to be a non-regression issue and marking it as untriaged.

Event handling is typically not related to V8.

It sounds Promise's issue.

yhirano@, domenic@,
I appreciate if you could triage this issue.

Do you know which bug components we should use for Promise?
Blink>DOM>Events is not appropriate, I think.

joshkel@, I can see the message when the html and js files are served via http. I cannot see it when they're loaded as file:// resources. Do you agree with it?

window.onerror behaves similarly. Can you check with the following code?

window.onerror = function(e) {
  alert(e);
}

throw 77;

cc-ing mkwst@ as he added ExecutionContext::shouldSanitizeScriptError. If this is the intended behavior, please let me know.

If the script is cross-origin to the page, then the page should be getting a sanitized error (e.g. "Script error." as opposed to a detailed error message with a stack trace) via `window.onerror`. It looks like the unhandled rejection flow errors out entirely rather than firing a sanitized event (see step 2 of https://html.spec.whatwg.org/multipage/webappapis.html#the-hostpromiserejectiontracker-implementation).

domenic@, jochen@, was that intentional?

the script error would have zero information, so we figured it's not worthwhile to throw it

https://github.com/domenic/unhandled-rejections-browser-spec/issues/20 has fragments of the discussion :-/

Hrm. It seems like there would be exactly as little information in this as there is in the `window.onerror` event. If we don't consider the one worth sending, why do we send the other? Consistency seems like a reasonable goal here.

in the other case it tells you that the entire script was not executed. For unhandled exceptions, you can only guess what happened

> the entire script

What entire script? It tells you that you had a "Script error." :) But yeah, there's some distinction in behavior between an uncaught exception and an unhandled rejection.

Assigning to Domenic to decide whether or not to change the spec here

I don't think we should change the spec, since as stated it's useless. But if people have some use case for getting some kind of censored version of the event (I guess with both `promise` and `reason` set to null??), please raise that on the HTML spec issue tracker.

Thank you for the explanation. I didn't realize that cross-origin policy was what was causing my event handler to fail.

I did some more testing with that knowledge, and I think there may still be a bug. My original scenario was that my unhandledrejection handler wasn't working in a React application, served using webpack-dev-server.  I went back to that today and did some more investigation and found that the event handler fires as long as Chrome Dev Tools are closed.  If Chrome Dev Tools are open, the unhandledrejection handler is ignored.

I've noticed that scripts are listed in Chrome Dev Tools with webpack:// URLs. Does translating the "real" URLs (e.g., http://localhost:8000/assets/app.js) to webpack:// URLs cause them to appear as coming from a different origin, causing unhandledrejection events to appear as cross origin and be ignored?

If you'd like for me to open a new issue for this or put together a full test case using webpack-dev-server, please let me know.

Remove Blink>DOM>Events

 Issue 876248  has been merged into this issue.