Bugzilla

Hey! Honza and I were talking about this exact issue this yesterday and example of a known issue but I wasn't sure if we actually had anything filed to track it. This is an issue with the debugger itself, rather than the console, so switching Bugzilla components. 

Clicking the URL on the console message instructs the debugger to open the file and that function *is* passed enough information that the debugger should be able to open the "eval"-ed source file, even if jQuery is also loaded on the page, we just do a bad job of it right now which is why this breaks. We see "oh these have the same URL, treat them the same", which is not what we should be doing.

My personal expectation for expected behavior here is that the source in the source tree for any particular URL would be the most recent source file that we've seen with that URL (possible per-target or something), so since jQuery's script is later, that one would be what you get if you open the debugger and manually navigate to the source file in the directory tree.

If you click the link in the console, you should always get the actual source that did the logging, as long as the source is still loaded in the page. If the console is configured to persist logs and you refresh the page, or you have a log for an iframe that closed or something, the source will no longer be loaded in the debugger, and we'd probably want to show some kind of error in the case clicking the message URL of the eval log since there no source data to show, and if you click on a persisted log for a file that had a real non "sourceURL" URL, then at least we could open the view-source page for that URL.

Hey! Honza and I were talking about this exact issue this yesterday as example of a known issue but I wasn't sure if we actually had anything filed to track it. This is an issue with the debugger itself, rather than the console, so switching Bugzilla components. 

Clicking the URL on the console message instructs the debugger to open the file and that function *is* passed enough information that the debugger should be able to open the "eval"-ed source file, even if jQuery is also loaded on the page, we just do a bad job of it right now which is why this breaks. We see "oh these have the same URL, treat them the same", which is not what we should be doing.

My personal expectation for expected behavior here is that the source in the source tree for any particular URL would be the most recent source file that we've seen with that URL (possible per-target or something), so since jQuery's script is later, that one would be what you get if you open the debugger and manually navigate to the source file in the directory tree.

If you click the link in the console, you should always get the actual source that did the logging, as long as the source is still loaded in the page. If the console is configured to persist logs and you refresh the page, or you have a log for an iframe that closed or something, the source will no longer be loaded in the debugger, and we'd probably want to show some kind of error in the case clicking the message URL of the eval log since there no source data to show, and if you click on a persisted log for a file that had a real non "sourceURL" URL, then at least we could open the view-source page for that URL.

Hey! Honza and I were talking about this exact type of issue yesterday as example of a known issue but I wasn't sure if we actually had anything filed to track it. This is an issue with the debugger itself, rather than the console, so switching Bugzilla components. 

Clicking the URL on the console message instructs the debugger to open the file and that function *is* passed enough information that the debugger should be able to open the "eval"-ed source file, even if jQuery is also loaded on the page, we just do a bad job of it right now which is why this breaks. We see "oh these have the same URL, treat them the same", which is not what we should be doing.

My personal expectation for expected behavior here is that the source in the source tree for any particular URL would be the most recent source file that we've seen with that URL (possible per-target or something), so since jQuery's script is later, that one would be what you get if you open the debugger and manually navigate to the source file in the directory tree.

If you click the link in the console, you should always get the actual source that did the logging, as long as the source is still loaded in the page. If the console is configured to persist logs and you refresh the page, or you have a log for an iframe that closed or something, the source will no longer be loaded in the debugger, and we'd probably want to show some kind of error in the case clicking the message URL of the eval log since there no source data to show, and if you click on a persisted log for a file that had a real non "sourceURL" URL, then at least we could open the view-source page for that URL.

Hey! Honza and I were talking about this exact type of issue yesterday as an example of a known issue but I wasn't sure if we actually had anything filed to track it. This is an issue with the debugger itself, rather than the console, so switching Bugzilla components. 

Clicking the URL on the console message instructs the debugger to open the file and that function *is* passed enough information that the debugger should be able to open the "eval"-ed source file, even if jQuery is also loaded on the page, we just do a bad job of it right now which is why this breaks. We see "oh these have the same URL, treat them the same", which is not what we should be doing.

My personal expectation for expected behavior here is that the source in the source tree for any particular URL would be the most recent source file that we've seen with that URL (possible per-target or something), so since jQuery's script is later, that one would be what you get if you open the debugger and manually navigate to the source file in the directory tree.

If you click the link in the console, you should always get the actual source that did the logging, as long as the source is still loaded in the page. If the console is configured to persist logs and you refresh the page, or you have a log for an iframe that closed or something, the source will no longer be loaded in the debugger, and we'd probably want to show some kind of error in the case clicking the message URL of the eval log since there no source data to show, and if you click on a persisted log for a file that had a real non "sourceURL" URL, then at least we could open the view-source page for that URL.