Bumping to P1, M61 given that this blocks the devtools MVP bug which blocks ES6 Modules (targeted at M61).

allada@ Do you have cycle to work on this bug? This will block ES6 modules ship.

I think we can simply plumb the ModuleScriptFetchRequest::referrer_ to the inspector

allada: Would you give update on this?

Yep sorry this slipped through my email.

I will look into it today and give an update :-)

I took a look into what is going on here and the fix will not be able to be squeezed into this quarter. We can add it to our Q3 OKR.

I am not convinced that we can use ModuleScriptFetchRequest::referrer_... It appears that we can easily loose the referrer if the policy deems so.

I believe the best thing to do is to have V8 pass a ScriptLocation of when a new module resource is added to the module tree.

Is adding it to Q3 OKRs good with you?

https://chromium-review.googlesource.com/c/539565/

V8 API change landed: https://chromium-review.googlesource.com/c/541322/

I think it would be very helpful to know (by order of priority) -
1. The specific module that first triggered loading this module.
2. All of the modules that would have triggered loading this module.
3. Perhaps there should be a module-dependency panel/drawer for showing all of the relationships and dependencies. But this is probably too fancy.

The point is that sometimes loading (running) a module may cause bugs and knowing the way that brought this module to the application would make it much faster to fix.

We're working on module-specific features, and I think we'll cover all mentioned use cases. Thanks!
But this particular issue is fixed by [1].

[1] https://chromium-review.googlesource.com/c/539565/

lgtm! thx

Deleted: Screen Shot 2017-06-29 at 11.04.00 AM.png 199 KB

	Screen Shot 2017-06-29 at 11.04.00 AM.png 199 KB View Download