New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 635154 link

Starred by 4 users

Issue metadata

Status: Archived
Owner:
Last visit > 30 days ago
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

DevTools: Expose network lifetime of resource

Project Member Reported by paulir...@chromium.org, Aug 5 2016

Issue description

Debugging in console and Sources deals with resources.
But they originally came over the network as requests. 
They're two separate things, but it's valuable to understand the connection between them.

For example, you get a mysterious exception like so:
> Uncaught SyntaxError: Unexpected token <   (index):1

(index) points to the first line of your HTML, and there is no stack attached.
Hard to debug past here, but in this specific case, the cause was a <script src> pointing to a URL that was 302 redirected to some HTML.

Here, it was be valuable if the (index) resource was annotated as: 
     0ms  Received as document
    13ms  Redirected from filethat302s.js


The example above comes from  Issue 544671 .
Seth, I remember you having an idea along these lines before. Is this similar?
 
Cc: kozyatinskiy@chromium.org
 Issue 544671  has been merged into this issue.
Yes, this is exactly the issue I've run into. Rather than designing a general solution which allows tying requests to all resources (which sounds like a hard problem), can we just warn when a script source redirects to anything other than content type "application/javascript" (or "text/javascript")?

Comment 3 by teo8...@gmail.com, Aug 21 2016

> can we just warn when a script source redirects to anything other than 
> content type "application/javascript" (or "text/javascript")?

No, that's just a partial solution for a particular case of this issue. Or for a different issue that has an intersection of use cases with this one.

Actually, that is a good idea per se and should definitely be done, but it doesn't solve this issue.


Here's a use case not addressed by the proposed fix:

Main html page:
  ...
  <script src="script1.js"></script>
  <script>/* does stuff */>
  <script src="script2.js"></script>

and the server redirects script2.js to script1.js.

A runtime error occurs only when running script2.js.
>> debug nightmare.


Now, this makes me think of another issue, whose fix COULD perhaps be a viable and acceptable alternative to the true fix for this issue:

The stack trace of an error should include, at the end, the line of HTML where the <script> tag was found if the error is in a js file.

For example here:
http://matteosistisette.com/test/stupidchrome/jserror/
the current stack trace is:
  script1.js:4 Uncaught ReferenceError: khsbdc is not defined
               issueError @ script1.js:4
               (anonymous function) @ script1.js:1

Should be something like:
  script1.js:4 Uncaught ReferenceError: khsbdc is not defined
               issueError @ script1.js:4
               (anonymous function) @ script1.js:1
               (script tag) @ (index):4

  
Components: Platform>DevTools>Authoring
Owner: allada@chromium.org
Blaise, could you please take a look?
Status: Archived (was: Assigned)

Sign in to add a comment