@Reporter: I followed the below mentioned steps to reproduce the issue
1.Downloaded the zip file provided and extracted it.
2.In terminal, we have set the path where the extracted folder is present.
3.And run the python -m SimpleHTTPServer
4.Navigated to localhost and Loaded index2.html page in browser
5.Finally checked the console output.It says,"Imported resource from origin 'file://' has been blocked from loading by Cross-Origin Resource Sharing policy: Invalid response. Origin 'null' is therefore not allowed access".

Providing the screenshot of network for reference, are the steps mentioned above are correct and the let us know about your expected result. 

Deleted: 767841.png 135 KB

	767841.png 135 KB View Download

You should be accessing the site via: http://localhost:8000/index2.html - not from the filesystem. Your screenshot shows you loading the index file from the filesystem.

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue on 61.0.3163.91 and on latest canary 63.0.3225.0 using Mac 10.12.6 and is not reproducible with steps mentioned in comment#0 and comment#3. i.e;  No console output is seen. Attaching screecast for reference.

@Reporter: Could you please find the attached screenshot and also please attach a expected screenshot from your end. That would help us in further triaging of the issue.

Thanks in advance!!

Deleted: 767841.mp4 699 KB

	767841.mp4 699 KB View Download

Hi - You're screencast shows the issues. The console shows an undefined and an Uncaught error - that shouldn't happen if things were working correctly. Polymer should be defined and printed out on the console. The dependencies are not loading before the console.log statements are being executed.

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hello
Here's a plunker about the problem.
http://plnkr.co/edit/Uz2yenOxF3CcGqUatKQG?p=preview

There are 4 files:
- dependency.html : set window.dependency = true.
- index.html : imports (using HTML-imports) module1.html and module2.html.
- module1.html :  imports (using HTML-imports) dependency.html, and says if it has been imported in an inline module.
- module2.html :  idem and adds an empty inline script.

You will be able to see that inline script module are runned after the HTML-imports only if we add an empty inline script tag, with at least one character inside, in the html file.

Thanks for the report.
As you may know, <script type="module"> runs in "defer" manner, which means
the execution starts after all loading is done, while HTML Imports (+ classic
scripts) have stricter ordering of execution/import.

As of now we don't have any formal definition of how module scripts interacts
with the HTML Imports dependency resolution / script execution order, so a
module script within an import may execute before all the HTML Imports are
processed.

Maybe we may defer modules scripts' execution after all HTML imports are
processed, but I'm wondering how important is it because if you have
a module script inside an import, the dependent imports cannot use
the side effect of the module script execution as it runs in "defer" manner.

Wouldn't it be nicer if module scripts, rather than being defered untill all loading are done, would defered untill all *needed loading are done.

In our case, where index imports 2 modules, which import their dependencies, it would mean that the 1st module script runs after all its html-imports from its own file, but before the 2nd script module's imports.

I see your point, and it sounds nice if module scripts run the way
you explained.

But as HTML Imports are not under active development, and is unlikely
going to be supported by other browsers, implementation for the semantics
is quite low from our perspective.

So, because HTML imports are going to disapear (they aren't and won't be part of the standards), then the way they run with ES6 modules is definitly not going to change.
Then, the only way to make an imported module (via HTML import) wait for its own needed imports, is to use an hack solution by adding an empty inline script next to it (as shown in the sample). This will force the HTML imports to start to execute before the the execution of the empty inline script.

Polymer is transitioning away from HTML imports and onto ES modules, and we just ran into this timing issue. It would be quite helpful to be able to rely on type=module scripts always executing after HTML imports are loaded, because it makes it possible to reliably mix the two systems, which is important for incremental migration.

For example, you might have a document that bridges the two by importing one dependency via an HTML import, and another via an ES module import. However, as it stands today, as soon as you switch your script type to "module" in order to perform the ES module import, any existing code that depended on the HTML import being loaded will likely break.

The no-op script hack does seem to work, but I imagine most users are not going to discover it, so I worry that this will add friction for users trying to migrate away from HTML imports.

@aomarks thanks for providing good rationale for having this fixed, as
an answer to my question in comment #14.  Let me clarify my understanding.

Imagine this document structure (<script> is classic, <script type=module> is ES module):

Document
 +- <script> A
 +- <script type=module> A'
 +- Import1
    +- Import2
    |  +- <script> C
    |  +- <script type=module> C'
    +- <script> B (Note: belongs to Import1)
    +- <script type=module> B' (Note: belongs to Import1)
 +- Import3
       +- <script> D
       +- <script type=module> D'
 +- <script> E
 +- <script type=module> E'

The classic scripts' order should be deterministically A-C-B-D-E.
Maybe your case doesn't care for A',B',C', and D' but only cares about E'
is executed after all A-C-B-D, without needing "no-op" script E?

Or as the comment 16, you also expect strict determinism like
A-(A'?)-C-C'-B-B'-D-D'-E-E'?

(or A' still can be deferred between E and E')?

Ah, the example in the above comment #20 was not to the point,
the repro case in #12 is more precise.

So within an import file, a module script can be executed before its
dependency loading is complete.