1622158 - Conflicted //# sourceURL directive hide one of the source file from source panel

Status: NEW

(DevTools :: Debugger, defect, P3)

Description

[mmis1000]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

1. Add a script that has eval noted with sourceURL
2. And a script with src to page

    <script>
      eval(`
        console.log('test')
        //# sourceURL=https://code.jquery.com/jquery-3.1.0.js
      `)
    </script>
    <script src="https://code.jquery.com/jquery-3.1.0.js">

Actual results:

The former always mask the latter if url is exactly the same.

In above case

The script execute latter was completely masked by the eval running first in source panel

https://i.imgur.com/RpuI8lv.png

Expected results:

The source panel should show both.
Either with same name or different name.

And have a way to differ which is the script physically loaded and which is the script declared by //# sourceURL directive

Comment 1

[mmis1000]

Chrome seems just ignore the protocol and domain parts completely in this case.
Only the filename was shown in the console.

https://i.imgur.com/SXMNSgG.png

And filename was also prefixed by a VM\d+ label

Comment 2

[Daniel Bodea [:danibodea]]

You are comparing the "Debugger" DevTools tab from Firefox with the "Console" DevTools tab from Chrome. To me, it appears that this script provides the same behavior for both browsers.

You should be comparing the "Sources" Devtools tab from Chrome with the "Debugger" DevTools tab from Firefox and also, you should compare the "Console" from Chrome with the "Console" from Firefox.

Please explain in more detail if I misunderstood the issue.
Thank you for your contribution!

Comment 3

[mmis1000]

The biggest problem I though of is. You now have no way to debug the script masked by the eval . All stack trace now jump to the fake script becuase the name was taken by the eval.

Comment 4

[mmis1000]

Another problem I could concern of is, You should not be able to claim you are a script of other domain. But this can actually be used for some proxy that accelerate the page loading by inlining resource while keeps file name correct. So I am not really sure whether this should be allowed or not.

Comment 5

[mmis1000]

Besides this, chrome isn't even showing the script in the source panel (possibly because such filename claim is invalid.)
https://i.imgur.com/cLwSofH.png

Comment 6

[Daniel Bodea [:danibodea]]

I cannot confirm your issue since I cannot fully understand it, but I can set its component to (DevTools) Console and let it be picked up by somebody how can properly triage it.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:nchevobbe, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Nicolas Chevobbe [:nchevobbe]]

mmis1000, do you have a concrete case where this is a problem for you?
From my quick testing, yes the script is masquerading as something it's not, so the location of the messages (and I guess stacktraces) are not the "real" one, but U think this is used by utilities (like hot reload ?) to actually link back to the original files?

I'm not sure at all, Logan could probably better see if this is an issue.

Comment 9

[mmis1000]

That actually breaks firefox dev tool itself. click the stacktrace now link to the wrong file, debugger point no longer works correctly because file got overridden by conflict.

Comment 10

[Logan Smyth [:loganfsmyth]]

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.

Comment 11

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 12

[Logan Smyth [:loganfsmyth]]

Clicking on the log location in the console message should now be guaranteed to open the correct file in the debugger, so I think this is good to close. Would you be able to verify this behavior on Nightly and close this?

This bug has a bunch of tangential points that it has raised, but I think that many of them are unlikely to change. If two scripts claim to have the same URL, we'll only show one of them, which one is a bit up in the air, but that is true with or without the sourceURL pragma. You could also have changed the script and injected a new <script> tag to load the new version of a file or something, to again end up with 2 scripts with the same URL and different content. It's up to developers to do that in a way that works well.

Comment 13

[mmis1000]

Yes, the devtool now leads me to the correct evaled source instead of code of actually source.

But the source view now also show me the evaled source after the navigation.
Is that a intended bahavior?
The jquery script is loaded after the eval, shouldn't that the actual script show in source view instead?