Able to reproduce the issue on chrome version 60.0.3072.0 ,reported version #68.0.3440.106 and on latest chrome #70.0.3530.0 using Mac OS 10.13.6,Windows 10 and Ubuntu 17.10 by following below steps.

Steps:
=====
1.Launched chrome.
2.Downloaded and opened the file unhandledrejection.html.
3.Clicked on run case 1, run case 2 and run case 3, observed that when clicked on run case 1 and run case 2 a alert message "unhandledrejection catched: promise reject in constructor" and no alert message on clicking run case 3.

This is a non regression issue and this behaviour is observed from old M-60 builds. Hence marking it as untriaged and requesting dev team to look into the issue.
Thanks.!

Shiino-san, could you take a look on this?

Hirano san, would you triage this issue?  This issue seems a promise's issue.

I can reproduce the issue with 70.0.3534.4, but NOT on the ToT.  A recent change might have already fixed the issue.

I cannot reproduce the issue with Version 68.0.3440.106 (Official Build) (64-bit) on Linux.

Now I can reproduce the issue. The issue is reproducible if the HTML file is accessed as a file:// URL.

Please see https://bugs.chromium.org/p/chromium/issues/detail?id=655694#c9 and https://bugs.chromium.org/p/chromium/issues/detail?id=655694#c16.

Re-opening.

yukishiino@ pointed out that the inconsistency among three cases is probably a bug.

One correction: It is reproducible on ToT. yukishiino@ ran the test with --allow-file-access-from-files, which hid the problem

This is a binding issue. CORS itself it not related.

"CORS itself is not related", I mean.

Specifically, it seems we fail to set the "muted errors" flag correctly.
https://html.spec.whatwg.org/multipage/webappapis.html#creating-a-classic-script

I found that the issue goes away if we reject a promise with an Error instance.

 window.runCase3 = function (){
   new Promise((resolve) => {
     resolve(1);
   }).then(() => {
     return Promise.reject(Error('promise reject in then & return'));
   }).then(() => {});
 }

This is because the stack frames are stored in the Error instance at the construction time.

Domenic, is it what we want to rely on?

No, the `reason` property should be set to the rejection reason, regardless of what the reason's JS type is.

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

commit c4bffcd56d2fe3111c9937b359ce01e4e02c875e
Author: Yutaka Hirano <yhirano@chromium.org>
Date: Thu Sep 06 07:12:20 2018

Use ScriptOriginOptions with IsSharedCrossOrigin set for empty script

Currently, neither IsSharedCrossOrigin nor IsOpaque is set for an empty
script. Hence an exception thrown from it (e.g., an exception thrown
from native promise implementation) is treated as an error with
blink::kNotSharableCrossOrigin. On the other hand, as the script is
empty, there is no meaningful URL attached, which means the
ExecutionContext's URL is used as the script's name in
blink::SourceLocation::FromMessage. In other words, it works virtually
as same as blink::kSharableCrossOrigin corresponding to
ScriptOriginOptions with IsSharedCrossOrigin set and IsOpaque unset.

With this CL, a ScriptOriginOptions with IsSharedCrossOrigin is set
and IsOpaque is not set is attached to the empty script, as a
preliminary step to deprecate kNotSharableCrossOrigin.

Bug: chromium:875153, chromium:876248 
Change-Id: I39279a43994337329b8bd9d28b6ca29f0ac30d9c
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1201689
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55673}
[modify] https://crrev.com/c4bffcd56d2fe3111c9937b359ce01e4e02c875e/src/heap/setup-heap-internal.cc
[modify] https://crrev.com/c4bffcd56d2fe3111c9937b359ce01e4e02c875e/test/cctest/test-api.cc

The behavior difference between file:// and http[s]:// is fixed.